What is Perl Testing?

Various testing methodologies have become a corner stone for many of the development processes and PERL testing is one such testing methodology. 

"Perl testing is one such testing that is highly involved with the creation of automated test suites".

The creation of automated test suites with regard to the perl projects is assisted by around 400 testing and quality modules which are now available on the CPAN.

Now you must be thinking why only automated test suites in perl? 

The answer is that the with an automated test suite the developers as well as the project managers get a sense of confidence in the ability of the code that it can very well carry out a specification. 

What is Perl Testing?

- Perl development ethos has always viewed software testing as its central and critical part since years. 

- Gradually, a testing protocol by the name of TAP or ‘test anything protocol’ was set up for the perl in the year of 1987. 

- This TAP protocol is now available for so many languages. 

- Many of the test modules on CPAN like 100s make use of this TAP protocol. 

- With the help of this protocol it has been made possible to enable the following aspects:

1. Testing of data base queries
2. Testing of objects
3. Testing of web sites and so on.

- Around 250,000 tests have been developed for the core Perl language plus there are a same number of tests for the libraries that are associated with it. 

- There is one more advantage of the automated test suites which is that the additions are done to the code base as the changes in functional requirements are experienced. 

- But, while making the additions, re-factoring is required so as to avoid duplication. 

- Since, if there is enough code coverage the issues will automatically be highlighted by the test suite and then it becomes fairly easy to spot the changes that occur in the knock on effects of code. 

- The duty of the code coverage is to determine how much of the code has been tested since the execution of the test suite. 

- This metric however can be obtained from the developer and also the branches and sections of the code that are not being tested can also be reported. 

- Testers can combine the testing modules that are most frequently used and thus it serves a good starting point. 

- So, for the cases in which testing specific functionality is required, one only needs to add specific testing modules to the test.

- Perl has always recognized testing as a part of its culture. 

- With the TAP protocol, the communication between a test harness and several unit tests has been made possible. 

- The TAP producers can make communication regarding the test results to the testing harness in a way that is language agnostic. 

- Earlier the parser and producers were available for only this platform but now they are available for a variety of platforms. 

- The responsibility for the following purposes is taken up by the test anything web site:

1. Development of TAP
2. Standardization of TAP
3. Writing of test consumers
4. Writing of test producers
5. Evangelization of the language and so on.

- In many other testing methodologies, writing the tests and verifying them seems like to be a daunting task but it is pretty easy with the perl test facilities. 

- It is not always necessary that a large perl project must have an automated test suite. 

What is a Module? What is a Compiled Module? (In WinRunner)

Modules are the basic elements of any software system or application that make up the foundation of that software system or application. In winrunner usually the term “compiled module” is used. We shall see in this article that what are the compiled modules and how they can be created in winrunner. 

What are Compiled Modules?

- Compiled modules store the frequently used functions and so are considered to be a kind of libraries. 

- In compiled modules, the functions defined by users i.e., the user defined functions can be stored and later these stored user defined functions can be called from the test scripts. 

- Compiled modules are considered to be a library since they are actually a script containing all the user defined functions which are required to be called many times from other tests. 

- Whenever a compiled module is loaded, the functions that it contains are subjected to automatic compilation and reside in the memory itself. 

- After this, they can be called directly and from within any test. 

- With the compiled modules, the performances as well as the organization of the tests that you create are improved significantly.

- This happens so because the compiled modules are debugged before they are used and therefore the tests that we created require very less error- checking. - In addition to all this, the interpretation of a function in a test script is quite slower than the calling of a function that has already been compiled.

There are 2 ways available for compiling a module as mentioned below:

1. Loading the module to be compiled from a test script with the help of the TSL load function.
2. Running the script of the module to be compiled with the help of the winrunner run commands.

- The step commands can be used for performing the incremental compilation if in case you need to debug or modify an already existing module. 

- After this, the part of the compiled module that you made changes to needs to be run so that the entire compiled module will be updated. 

- It is necessary that the user defined functions present in your compiled modules are automatically compiled every time the winrunner starts up. 

- For this you need to add load statements top the start up tests. 

- However, you should know that for loading the recovery compiled module there is no need for adding the load statements to the start up tests or any other tests.

- This is so bacuse the recovery compiled module loads by itself when the winrunner is started. 

- Another point to be taken care of is that the compiled modules cannot load the GUI map files when you are working in the GUI map file per test mode.

- If the compiled module has to make references to any of the GUI objects present in the application software then it is required that the referred GUI objects must also be referred in the test which is responsible for loading that particular compiled module. 

- Like a regular TSL test the compiled module can be opened, edited or saved.  - However, there is a big difference in the contents of a compiled module or ordinary tests. 

- Like a regular test, a compiled module does not contain any analog input or check points. 

- This is so because a compiled module is designed to store user defined functions rather than just performing a test. 

- The purpose why it stores all the frequently user defined functions is to speed up the execution process by providing a quick and convenient access from the other tests. 

- Its contents are:

1. Function definitions and declarations,
2. External functions prototypes
3. Load statements etc.