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. Your utils.qft, which you hopefully saved in the previous section 6.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.

Open a new suite now with the »File«-»New 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 doesn't matter.

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 utility suite. 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 5.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 5.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 5.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 7.1:  Utility Suite utils.qft

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 7.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 7.3:  Sequence-Node with Recorded Click

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 6.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 utils.qft#checkbox.setState. Don't forget to fill in the variables as we did in section 6.8, with "select" set to 'false.'

		Figure 7.4:  Procedure Call to utils.qft

Instead of making procedure calls containing an explicit reference to the test-suite such as with utils.qft#checkbox.setState, QF-Test 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 7.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.

If you recall the discussion back in section 7.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 7.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 which utilizes utils.qft.

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 7.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 function.

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 inside of 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 7.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: 04/23/2012 Copyright © 2002-2012 Quality First Software GmbH