Test Technology and Framework

Selenium tests

Developer How-to Document









How to write the Project.net web acceptance tests

Vladimir Malykhin, February 2008

Overview:

There is introduced JWebUnit library into the Project.net. Henceforth there is possibility to develop the automatic web acceptance tests (a-tests). It means testing of web UI.

JWebUnit is a Java framework that facilitates creation of acceptance tests for web applications. It evolved from a project where we were using HttpUnit? and JUnit to create acceptance tests. As the tests were being written, they were continuously refactored to remove duplication and other bad smells in the test code. JWebUnit is the result of these refactorings.

So JWebUnit is based on HttpUnit?, a Java library for the automatic testing of Web applications, and the JUnit unit-testing framework. JWebUnit provides a high-level API for navigating a Web application, combined with a set of assertions for verifying the correctness of navigation via links, form entry and submission, table contents, and other typical business Web application features. JWebUnit comes in the form of a JAR file that's easily pluggable into most IDEs and includes other required libraries. Automated testing for Web applications means bypassing the Web browser and working with the Web site through our code. HttpUnit? can emulate frames, JavaScript?, page redirection cookies, and so on. When used with JUnit, HttpUnit? can quickly verify a Web site's functioning.

Also there is the automation of the run process with Continuum with ability for "continuous integration". Actually we don't need to QA’s manual pass of tests. We may automate this process by web a-tests. So Project.net may save resources. Automated testing saves the time and effort of performing the same test steps repetitively.

How to develop new test cases:

At first step we are developing the base set of a-tests for UI actions of all Project.net. For example "login", "create new business", "edit some properties" tests, etc. Second step: When we will have these tests, we may "extract" the own Project.net a-testing framework. Let's imagine an internal set of utilitarian classes/methods for a-testing of Project.net. So each developer (when he writes new code) in development time can write acceptance tests for UI which he is working on. Developer should invoke framework's methods, for example:

public void testSomeNewUI() {
    PnetATestFramework framework = new PnetATestFramework ();

    framework.login("appadmin");
    framework.gotoPortfolios();
    framework.createNewProject("someProject");
   
    // testing of new UI
    // developer need to add own testing code
    // asserts...
}

The current structure of the pnet a-testing available at \trunk\test\acceptance\src\net\project\test\acceptance

  • net.project.test.acceptance.engine.PnetTestEngine?.java (extends WebTestCase?) – main setup and additional engine of test methods
  • net.project.test.acceptance.framework.PnetATestFramework.java (extends PnetTestEngine?) – the Pnet web acceptance testing framewok has the test methods of pnet’s level logic
  • net.project.test.acceptance.AllTests?.java – registration of test suites
  • net.project.test.acceptance.LoginTest?.java – login page’s tests
  • net.project.test.acceptance.PersonalHomeTest?.java – Personal Home tests (see attached xsl file)

Test development process (near the ideal):

  1. Create new test for expected logic/UI before these code implementation (testing first).
  2. Make test “red” (run test to be sure that test is failed)
  3. Implement necessary logic/UI code
  4. Make test “green” (run test to be sure that tests is passed)
  5. Refactor code and test
  6. Run all available app tests
  7. Synchronize with repository
  8. Try to get updates
  9. If some updates are available then make test “green” (run test to be sure that tests is passed)
  10. Commit your changes (test and implementation)

On the qa.project.net server we have automatic build/deploy/test system with the Continuum engine.

Actually, we may have some problems with testing tricky JavaScript? logic, such as Drag-and-Drop functionality.

So we will have the set of Project.net web a-tests for the front-end app layer. We are extracting test engine to so-called "pnet test framework". Also each developer, manager (and customer if need) may have ability to run the full set of a-test cases.

How to run:

These tests we may run on Tomcat and Weblogic servers as well. The pnet web a-testing framework uses the JWebUnit/HtmlUnit test engine (extended Junit test). So we may run those test cases as a JUnit tests.

Junit-compatible tests may run from:

  • Eclipse, Idea and others IDE with the JUnit tests running support
  • like as Ant <junit> task/target
  • java command line (ugly way)

Now I'm using Eclipse IDE and Ant target in development/perform process.

There is the “web-a-tests-running” Ant's target (/core/build-tomcat.xml). It takes a possibility to automatic running of tests on the server for continuous integration via Continuum (or CruiseControl?). This target performs web-a-tests-compiling. Actually before the run of web-a-tests-running, it needs to run local Tomcat app server with the Project.net deployed. The last version of web a-tests set and framework's methods is at pnet SVN trunk now.

If you would like to use Eclipse IDE:

  1. run localhost Project.net application server (Those tests we may run on Tomcat and Weblogic servers as well);
  2. open Project.net source code via Eclipse IDE (SVN trunk https://svn.project.net/svn/pnet-root/trunk);
  3. go to \test\acceptance\src\net\project\test\acceptance\ AllTests?.java;
  4. for this file please select menu Run -> Run As > JUnit Test;
  5. you should see tests performing (green - passed, red - errors, blue - failures).

References

Vladimir Malykhin, February 2008

PREVIOUS THOUGHTS:

Ant target for a-tests running

Vladimir Malykhin, January 2008

There are web-a-tests-running Ant's target (/core/build-tomcat.xml). This target performs web-a-tests-compiling. Actually before the run of web-a-tests-running, it needs to run local Tomcat app server with the Project.net deployed. The last version of web acceptance tests set and framework's methods is at pnet SVN trunk.

How to run a current set of the Project.net web acceptance tests

  1. run localhost Project.net application server (Those tests we may run on Tomcat and Weblogic servers as well);
  2. open Project.net source code via Eclipse IDE (SVN trunk https://svn.project.net/svn/pnet-root/trunk);
  3. go to \test\acceptance\src\net\project\test\acceptance\PersonalHomeTest?.java;
  4. for this file please select menu Run -> Run As > JUnit Test;
  5. you should see tests performing (green - passed, red - errors, blue - failures);

The pnet web a-testing framework uses the JWebUnit test engine (extended Junit test approach). So we may run those test cases as a JUnit tests.

Junit-compatible tests may run from:

  1. Eclipse, Idea and others IDE with the Junit tests running support;
  2. java command line (ugly way);
  3. and like as Ant junit task/target.

Tasks need to be done:

  1. Ant target for these tests running (It takes a possibility to automatic running of tests on the server for continuous integration with CruiseControl?, Maven, Continuum);
  2. tests performing-time optimization.

Project.net web acceptance testing plan

Vladimir Malykhin, June/July 2007

  1. Introduce of web acceptance testing framework - OK
  2. Research of Project.net web testing via the bunch of JWebUnit/HtmlUnit/Junit - OK
  3. Adding necessary libraries to the pnet Eclipse project - OK
  4. Work on the QA manual test cases - in progress
  5. Project.net Acceptance tests writing - in progress
  6. Special Ant target development

About the Project.net acceptance testing. I need to explain this point. So I introduced !JWebUnit into the Project.net. Henceforth we may develop the automatic web acceptance tests. It means testing of web UI. jWebUnit is based on HttpUnit, a Java library for the automatic testing of Web applications, and the JUnit unit-testing framework. jWebUnit provides a high-level API for navigating a Web application, combined with a set of assertions for verifying the correctness of navigation via links, form entry and submission, table contents, and other typical business Web application features. jWebUnit comes in the form of a JAR file that's easily pluggable into most IDEs and includes other required libraries. Automated testing for Web applications means bypassing the Web browser and working with the Web site through our code. HttpUnit can emulate frames, JavaScript, page redirection cookies, and so on. When used with JUnit, HttpUnit can quickly verify a Web site's functioning.

Refer to Wikipedia Acceptance Tests page.

In first step we going to develop base automatic acceptance tests for UI actions of all Project.net. For example "login", "create new business", "edit some properties" tests, etc.

Second step: When we will have these tests, we may "extract" the own Project.net acceptance testing framework. Let's imagine a internal set of utilitarian classes/methods for acceptance testing of Project.net. So each developer (when he writes new code) in development time can write acceptance tests for own UI. Developer need to invoke framework's methods, for example:

public someNewUITest() {
    ProjectNetATestsFramework atestsFWInstance = new ProjectNetATestsFramework();

    atestsFWInstance.login("appadmin");
    atestsFWInstance.gotoPortfolios();
    atestsFWInstance.createNewProject("someProject");
   
    // testing of new UI
    // developer need to add own testing code
    // asserts...
}

You also may view attached example of Project.net LoginTest method. So I will extract this method to the framework method: public login(String userName);

I used acceptance testing methodology in several java web projects. So we will have the set of Project.net web acceptance tests. Each developer, manager (and customer if need) will have ability to run the full set of acceptance test cases.

Also we may try to automate the run process with CruiseControl and/or Maven. When we will have it, we don't need to QA manual pass of tests. We may automate this process by web acceptance tests. So Project.net may save resources. Automated testing saves the time and effort of performing the same test steps repetitively.

References:

Initial thoughts about Project.net testing

I'm ready to write acceptance web tests with HttpUnit, JUnit and HttpClient. So we will have automatic test cases for web layer UI testing. After we can extract test engine to some "pnet test framework". Each developer must use a framework to write tests.

Actually, we may have problems testing tricky JavaScript logic, like Drag-and-Drop functionality. I would like to research and use a special JSUnit test tool library for JavaScipt testing. Also, we need to research the new test tools like as XML Test Suite, Anteater, WebCanoo, JWebunit.

Now I'm researching a current situation with tests in the /test folder in project and file archive on /pnet-internal-doc/Documentation/qa/ . Also, we may need to automate (write automatic tests) for the 900 manual test cases.

The main problem is that we don't have resources to write all unit tests for each class because the project has a lot of classes which many engineers wrote in the past. So if we say about time, team resources - we don't have real ability to write all tests and it is impossible to test existent code. It needs a lot of time to research other's code. I think we may write "post factum" tests only for UI (I mean web acceptance tests). However for the best result, developers must write new tests in "testing first" mode for new functional classes from now.

So how to increase of effectiveness, we must have the set of automatic test cases with ability for "continuous integration" - CruiseControl and/or Mantis. Also we need to the common test servers, like as "dev", "production" etc. The each test server must have their own DB instance with test data.

I agree with "smoke tests", but in my opinion by classical TDD methodology, each developer before commit must run the all test cases. But the key moment is on the amount of tests and time need for full execution.

Also, I think, the project must have a set of "stress tests" for testing Project.net in extreme conditions with heavy load.

Attachments