When working with the real project, it is necessary to somehow organize code repository to be able to easily locate the code. This can be achieved through placing functions and variables that are bound to a specific functionality, into separate units. This approach is called functional decomposition.
In this recipe, we will take on an example of such decomposition for testing the Calculator Plus.
- First of all, we need to find out which layers are going to break down the code of our project. Usually, there are three such levels:
- The level of the libraries: In this level, we create functions and classes that may be used in any project. For example, functions operating with strings, arrays, and databases (unbound to any specific database) and functions created for simplification of the data-driven approach, for working with the e-mails and another code that is liable to come in mighty handy not only in the given project, but in any project (both existing and prospective ones).
On this level, the units may apply functions from other units, only being on the same level (that is, on the level of the libraries).
- The level of the application's common code layer: Here we will go about creating functions to work with the application (or several applications) of the given project. For example, launching and terminating the application, login functions, and various checkers that are specific for the project.
Functions of this level can be used by other functions of the same level and the functions from the libraries (as this is the original intent of them having been created). Functions of this level in their turn, will be used on the next level of the tests.
- The level of the tests: In this level, we store only those tests, for example, scripts, which are meant to execute specific actions within the application. Functions of this level can apply other functions of the level of the libraries, and functions of the level of application code.
- The level of the libraries: In this level, we create functions and classes that may be used in any project. For example, functions operating with strings, arrays, and databases (unbound to any specific database) and functions created for simplification of the data-driven approach, for working with the e-mails and another code that is liable to come in mighty handy not only in the given project, but in any project (both existing and prospective ones).
- These three layers in TestComplete are easier to implement with the help of the folders that are created in the Scripts element. On each level, we will have several files, and that's why it would be logical to place them in separate folders.
Let's consider each level individually.
- Everything is quite simple with the level of the libraries. Here, for each of the library types, we have a separate unit; moreover, the name of each unit will correspond to the original intent of the inherent functions. For example,
StrLibis meant for working with the strings,DBLibin its turn is meant for working with databases, and so on. If such a level of abstraction is not sufficient (for example, when we have different functions for working with databases Oracle and MS SQL), one can create another folder within the libraries folder, and place therein several individual units, each having a set of functions for a singular database. - Level of the application code is more complex and depends much on the complexity of the tested application itself. Here, we need to break the code down into logical and functional applicability. For example, in order to test Calculator Plus, we may have the following units:
- Common: This unit can be used for functions of the generic intent: for opening or closing the application, clearing the results field, and so on.
- CommonOperations: This unit can be used for operations that are available from any modus operandi (summing up, subtraction, and work with the memory).
- ScientificOperations: This unit can be used for operations that are available only in the scientific mode (logarithms, exponentiation, working with the corners, and different numerical systems).
- ConversionOperations: This unit can be used to work with the functions that are available in the conversion mode only.
- Edit: This unit will comprise functions that correspond the Edit menu (copying and pasting).
- Help: This unit can be used to work with the Help menu (evoking the Help and About windows).
This structure can be changed as the tester sees fit, with the only reservation about the code being logically layered in the project.
- In the level of tests, a certain clear-cut structure should also be pursued to steer clear of confusion in the existing tests. For example, it is possible to store tests by organizing them according to the same principles that are applied to structure the application code. If you have some manual tests that you are trying to automate, stored according to an existing logic (for example, in the bug tracking system), you can duplicate the same structure into the TestComplete project. There are no stringent rules here, it is only important to avoid chaos.
- An example is depicted on the following screenshot concerning the way a project may appear in order to test the Calculator Plus application.
At first glance, it may appear that for such a small application as Calculator or Notepad, there is no sense in creating such a structure, however, the truth is just the opposite. The structured code is much easier to maintain and build up; and it's much easier to get your bearings straight in efficiently thought-through project. A small application with time may grow into a larger one, medium size application and then into an enormous one: if the rules are broken from the beginning, with time it will only be more difficult to recollect the whereabouts of things and the underlying reasons. The method of functional decomposition also allows creation of readable tests. Such tests consist of functions calls of the lower-level and grasping them is much easier than just written code, as the names of the called functions are usually self-explanatory. Such test is of easy understanding even for a person who is not well cognizant in programming.
If you have several different projects in your company that are applying TestComplete but that do not intersect with each other, it does make sense to organize the libraries into a separate project and store it separately. This, however, requires discretion at the point of making changes, since these changes will affect everything.
Also note that, changes in the application under test will affect the script code as well.