Automated Testing uses one computer program to test another computer program. In Joomla, we use PHP test programs to test our PHP Joomla code. With automated tests, we can run a set of tests repeatedly, and as often as we like.

There are basically two Strategies for automated testing

1. Automated Unit Testing
2. Automated System Testing

Automated Unit Testing

Unit testing tests each method of a class. For example, if we have a method that capitalizes the first letter of a string, we can call the method on the input “foobar” and we should get the output “Foobar”.

Automated System Testing

System Testing is similar to asking someone to execute each step one by one for a use case scenario and do all the validations at each step. For example to create a Tag a user would follow these steps:

1. Log in to the Application.
2. Go to Tag Manager and Click on New Tag Button.
3. Create a new Test Tag with all the default field values.
4. Validate if Test Tag was Successfully created or not.
5. Delete Test Tag and Validate the changes.
6. Finally Logout from the Application.

System test can also do exactly the same things, the only difference being that in the first option a user will execute all the steps and in System Testing a piece of code will do all the steps and test the use case scenario.

It is not feasible with Joomla to test every use case scenario. Instead, we try to test the core functionalities of the application.

Selenium Web Driver and Selenium RC

Selenium Web Driver along with Nearsoft driver for PHP-Selenium Binding are the tools used for writing test scripts for Joomla. Currently we have test scripts written using Selenium RC. Because Selenium RC is no longer supported, we are shifting from RC to Web Driver.

Selenium-WebDriver makes direct calls to the browser using each browser’s native support for automation. How these direct calls are made, and what features they support depend on the browser you are using.

For those familiar with Selenium-RC, WebDriver is quite different from what you are used to. Selenium-RC worked the same way for each supported browser. It ‘injected’ JavaScript functions into the browser when the browser was loaded and then used its JavaScript to drive the Application under Test (AUT) within the browser. WebDriver does not use this technique. Again, it drives the browser directly using the browser’s built in support for automation.

For more information related to Selenium Web Driver and RC you can also visit this link: http://docs.seleniumhq.org/docs/03_webdriver.jsp

A Brief Overview of the Testing Plan

We have divided the testing project into two main modules-

1. Frontend: what the users see when he/she opens the application.
2. Backend: the administration site which is used for managing the content from the backend.

We are developing test scripts for both during the time period of this project. Out plan of action is to complete System Test for all the backend menus, for modules like Components, Menus, Users, System etc. then test the CRUD for the backend module and finally shift towards working with the frontend part.

In the frontend section we have planned to touch each module of the frontend and write at least one test for each module, so that we can later on continue that work.

We are also going to reduce the data dependency amongst each System test, so that even if for some reason a Test fails, it won’t affect the other System Test results. We will also have a different file structure for both the frontend and backend Page class Files.

A Demonstration for running a System Test

Just before I end the article I would like you all to see a short demonstration of a system test file for Joomla run.

Please open the following URL:Joomla System Test Demonstration