Squish/Best Practices: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
this page in: [[:Category:Tools::Squish::RecommendedWayOfWorkingSpanish|Español]]
this page in: [[Category:Tools::Squish::RecommendedWayOfWorkingSpanish|Español]]


=The recommended way of working with Squish=
[[Category:Tools::Squish]]


Imagine you have been using Squish out-of-the-box for a while, recording and replaying test<br /> cases with none or only minor manual modifications to the test scripts. You have reached a significant<br /> amount of test cases, and most of them start with doing the same sequence of steps, e.g. logging in to<br /> a remote server by specifying a user name and a password and then clicking OK in a dialog.
= The recommended way of working with Squish =


The code for this could look something like below:<br />
Imagine you have been using Squish out-of-the-box for a while, recording and replaying test<br />cases with none or only minor manual modifications to the test scripts. You have reached a significant<br />amount of test cases, and most of them start with doing the same sequence of steps, e.g. logging in to<br />a remote server by specifying a user name and a password and then clicking OK in a dialog.


Now imagine, for some reason, a developer goes and changes your application to not use a line edit as the<br /> user name input field, but a QComboBox instead. Now you will need to go and manually re-record or at least<br /> change every single test case interacting with this login dialog.
The code for this could look something like below:<br /><code>def main():<br /> type(&quot;:Username_QLineEdit&amp;quot;, &quot;user&amp;quot;)<br /> type(&quot;:Password_QLineEdit&amp;quot;, &quot;mypassword&amp;quot;)<br /> clickButton(&quot;:OK_QPushButton&amp;quot;)</code>


Instead of creating test cases by simply recording them, as that would eventually lead to the problem above, the<br /> recommended way of working with Squish is to record and refactor. That is, you record a test case, or a piece<br /> of a test case, and refactor that into one or several functions that you then call from your test script.
Now imagine, for some reason, a developer goes and changes your application to not use a line edit as the<br />user name input field, but a QComboBox instead. Now you will need to go and manually re-record or at least<br />change every single test case interacting with this login dialog.


In the example above, you would create a login() function after you have recorded the first test case that<br /> involves logging in to a server. Then for all subsequent test cases, you call this login() function from<br /> your test script. In code, this would be:
Instead of creating test cases by simply recording them, as that would eventually lead to the problem above, the<br />recommended way of working with Squish is to record and refactor. That is, you record a test case, or a piece<br />of a test case, and refactor that into one or several functions that you then call from your test script.


And as a side-effect of us creating this method, we also parameterized the function call, so you can test<br /> the login dialog with different values by just adding additional calls to login().
In the example above, you would create a login() function after you have recorded the first test case that<br />involves logging in to a server. Then for all subsequent test cases, you call this login() function from<br />your test script. In code, this would be:


If the same change to the application as above would now be made by a developer, you would not need to change hundreds of test<br /> cases manually, but only one single function.
<code>def login(username, password):<br /> type(&quot;:Username_QLineEdit&amp;quot;, username)<br /> type(&quot;:Password_QLineEdit&amp;quot;, password)<br /> clickButton(&quot;:OK_QPushButton&amp;quot;)


===There are 2 articles in "Tools -&gt; Squish -&gt; RecommendedWayOfWorking":===
def main():<br /> login(&quot;user&amp;quot;, &quot;mypassword&amp;quot;)</code>


===T===
And as a side-effect of us creating this method, we also parameterized the function call, so you can test<br />the login dialog with different values by just adding additional calls to login().
* [[:Category:Tools::SquishSpanish::RecommendedWayOfWorkingSpanish|Category:Tools -&gt; SquishSpanish -&gt; RecommendedWayOfWorkingSpanish]]
* [[:Category:Tools - SquishSpanish - RecommendedWayOfWorkingSpanish|Category:Tools_ _SquishSpanish_ _RecommendedWayOfWorkingSpanish]]


===Categories:===
If the same change to the application as above would now be made by a developer, you would not need to change hundreds of test
 
* [[:Category:Tools|Tools]]
** [[:Category:Tools::Squish|Squish]]
* [[:Category:Tools::Squish::RecommendedWayOfWorkingSpanish|RecommendedWayOfWorkingSpanish]]

Revision as of 07:44, 24 February 2015

this page in:

The recommended way of working with Squish

Imagine you have been using Squish out-of-the-box for a while, recording and replaying test
cases with none or only minor manual modifications to the test scripts. You have reached a significant
amount of test cases, and most of them start with doing the same sequence of steps, e.g. logging in to
a remote server by specifying a user name and a password and then clicking OK in a dialog.

The code for this could look something like below:

def main():<br /> type(&quot;:Username_QLineEdit&amp;quot;, &quot;user&amp;quot;)<br /> type(&quot;:Password_QLineEdit&amp;quot;, &quot;mypassword&amp;quot;)<br /> clickButton(&quot;:OK_QPushButton&amp;quot;)

Now imagine, for some reason, a developer goes and changes your application to not use a line edit as the
user name input field, but a QComboBox instead. Now you will need to go and manually re-record or at least
change every single test case interacting with this login dialog.

Instead of creating test cases by simply recording them, as that would eventually lead to the problem above, the
recommended way of working with Squish is to record and refactor. That is, you record a test case, or a piece
of a test case, and refactor that into one or several functions that you then call from your test script.

In the example above, you would create a login() function after you have recorded the first test case that
involves logging in to a server. Then for all subsequent test cases, you call this login() function from
your test script. In code, this would be:

def login(username, password):<br /> type(&quot;:Username_QLineEdit&amp;quot;, username)<br /> type(&quot;:Password_QLineEdit&amp;quot;, password)<br /> clickButton(&quot;:OK_QPushButton&amp;quot;)

def main():<br /> login(&quot;user&amp;quot;, &quot;mypassword&amp;quot;)

And as a side-effect of us creating this method, we also parameterized the function call, so you can test
the login dialog with different values by just adding additional calls to login().

If the same change to the application as above would now be made by a developer, you would not need to change hundreds of test