|Modularization [30-45 min]|
In this chapter we will expand upon the concepts you learned in the previous chapters. Our goal is to show you how you can modularize test-suites. The features we'll be presenting to you here are a bit more advanced than those seen in earlier chapters, so we strongly recommend that you have gained a solid understanding of the concepts already covered before proceeding.
As you begin to develop test-suites specific to your own needs, you'll often run into situations where you are repeatedly, or perhaps redundantly, performing the same steps. Suite A, for example, may often require the usage of some menu operation in your SUT that Suite B also needs. Instead of having the same procedure in both suites, it is much more useful - and reliable - to have one common source for the procedure.
This brings us to the concept of a utility suite - or library - which
contains common procedures for use by any number of other test-suites.
utils.qft, which you hopefully saved in the previous
section 5.10, will then serve as a sort of library
that other test-suites can access for common utility procedures. The
advantage of such a structure is that you have a stable library of
routines which can be relied upon to perform their function accurately by
other test-suites. Such modularization of suites is easy to implement in
QF-Test, as will unfold in the following sections.
|Creating the Driver Suite|
Open a new suite now with the »File«-»New Test-suite...« menu option. With this test-suite you'll create a real test for the SUT, as we'll show in the following sections.
You should also bring up your
utils.qft test-suite, which
contains the "checkbox" package you wrote in the previous chapter.
Save the new driver suite in the same directory as
utils.qft. This is necessary so you can use relative path
names when one test-suite refers to the other. The actual filename
|What Belongs Where|
If the SUT application is not already running, start it up now. You'll
note that the startup nodes for the SUT are still located in
utils.qft. A true utility suite should have no direct
connection to an SUT. Why? Because the utility suite could be used by
other test-suites that test different SUTs.
For example, say you have two completely different SUTs 'A' and 'B'
which you must test. You would thus create two test-suites for each
SUT. However, in both SUT applications, checkboxes are present that
can be selected or deselected using your
Utils.qft must therefore be
general-purpose enough to handle this type of situation.
As it is now,
utils.qft contains elements that directly
link it to the Options Demo SUT, which we created back in section 4.1, i.e., the Setup/Cleanup nodes as well as
the "Windows and components" section. This SUT-specific information is
now irrelevant to the utility suite and should be moved over to the
test-suite which will be directly testing the SUT.
So, similar to the steps done in section 4.1,
you can now move the Setup/Cleanup nodes and the contents of the
"Windows and components" node to your new suite. Make sure to use the
»Cut« menu option instead of »Copy« so that the nodes are completely removed from
utils.qft. When you're done, your new test-suite should
look just like the skeleton we saw in figure 4.1. You can also clean out the procedure call
nodes you created in
utils.qft so that it is down to the
bare essentials as shown in the following figure:
||Figure 6.1: Utility Suite |
|Creating a Test Sequence|
In this section, you'll use your new test-suite to create a test sequence for the SUT. The test sequence will be a simple one: select the "Miscellaneous" window of the SUT and deselect the "Boolean option" checkbox.
After the Setup-node in your test-suite, insert a sequence-node with the »Insert«-»Sequence nodes«-»Sequence« menu option. Give it a name such as "Deselect Checkbox". Expand the node so that you can insert new nodes into it.
||Figure 6.2: Deselect Checkbox Sequence-Node|
Now click on the record button of your test-suite so that we can record a sequence. Bring up the window of the SUT and click on the "Miscellaneous" item under the "Preferences" list. You should see the "Miscellaneous Options" sub-window appear in the SUT. Return to your test-suite now and click the button to stop recording.
In the recorded sequence that appears in the your "Extras" node, you should just see just one event recorded, namely the click of the "Miscellaneous" item. Move this node into your new sequence-node, which should now look something like this:
||Figure 6.3: Sequence-Node with Recorded Click|
|Calling a Procedure in the Utility Suite|
The next step in the test sequence is to make a call to the utility suite to deselect the checkbox. As you did in section 5.8, insert a procedure call node to the procedure "checkbox.setState". This time, however, we need to add a slight modification, since the procedure is located in another test-suite.
Procedure calls in QF-Test can be prepended with the name of the suite in
the form of
suite#procedure to indicate that the target
procedure is located in the supplied test-suite. For our example, the
procedure call is correctly declared
Don't forget to fill in the variables as we did in section 5.8, with "select" set to 'false.'
||Figure 6.4: Procedure Call to utils.qft|
|Adding an Include|
Instead of making procedure calls containing an explicit reference
to the test-suite such as with
provides a simple mechanism which allows you to 'include' certain
test-suites as part of your overall test-suite structure.
An 'include' is an implicit reference to a test-suite. When QF-Test sees a procedure call node without an explicit reference to a test-suite (i.e., there is no test-suite name prepended with the '#' symbol before the name of the procedure), then it attempts to search within the current suite for the procedure being called. If the procedure is not found in the current suite, it then searches the test-suite's 'include list' for the procedure.
Click on the "Test-suite" root node of your test-suite. Within the
properties of this node, you'll see a section for "include files".
Within this list, add now the name of your utility suite,
utils.qft. Entries are added and modified in this list
just like you did with variables, using the small add, edit and delete
buttons. You should see something like this:
||Figure 6.5: An Include List|
NoteFor more detailed information about how QF-Test resolves issues concerning procedure calls, refer to the include file resolution section of the user manual.
|Modularization for Multiple SUTs|
If you recall the discussion back in section 6.2, a
utility suite such as
utils.qft should not contain any
direct references to the SUT client. If you scan through
utils.qft, however, you'll see that there are indeed
still such references to the Options demo. Take a look at one of your
"Check boolean: selected" nodes, for example, and you'll see the
reference to the client as such:
||Figure 6.6: Constant Reference to the SUT Client|
This direct reference will, of course, prevent you from using
utils.qft with other test-suites, but the solution is
simple. Instead of directly referencing the SUT, you will replace the
reference with a variable that can (and must) be set by the test-suite
So let's fix this now. Where-ever you see a reference to the "Options"
client, replace it with a variable reference, let's call it
$(client) as shown below:
||Figure 6.7: Variable Reference to the SUT Client|
You'll have to change all references to the client in
utils.qft, but QF-Test can make this a lot easier for you by
using the search/replace feature. Click on the top-level "Test" node
of the test-suite and select the »Edit«-»Replace« menu
The next step is, as you may suspect, to modify the driver test-suite
so that a value of the variable "client" is available when procedures
utils.qft are used. One way to do this is to
pass the "client" variable as an argument for each procedure call into
utils.qft. This kind of solution is perfectly viable, if
not a little manual-intensive and error-prone.
Another more elegant solution is to set the variable once in your
test-suite so that you don't have to think about it again. Expand your
top-level "Test-suite" node. Within the properties window of the
test-suite, you will see a section (beneath the includes and
dependencies) in which you can define variables for the test-suite.
Within this area, add the variable
client and give it the value of
Options like this:
||Figure 6.8: Setting a Default Test-suite Variable|
Once you've completed this step, you shouldn't have to worry about
this variable again until you create a new test-suite that uses
utils.qft. Your utility suite is now fully modular!
|Last update: 10/27/2017
Copyright © 2002-2017 Quality First Software GmbH