Chapter 3: Testing J2EE applications

Summary

Summary

Important

Important

Testing shoshould occur throughout the software lifecycle. Testing shoshould be a core activity of software development.

Tests must take place throughout the entire lifecycle of software development. Testing must be a core task of software development.

Test Cases shoshould usually be written before code. Instead of considering application code as the sole deliverable, test cases,

Documentation (Javadoc and other), and application code shocould be kept in sync, with the test cases being written first. If you can't

Write a test for a piece of code, you don't know enough to write the code itself. A test that isn't up-to-date is useless.

Unless tests are easy to run, they won't be run. it's vital that unit tests can be run automatically, and that there is no need to interpret the results-There shocould be a single indication of success or failure. ant can be used to automate tests written with JUnit.

It's important to invest a little time early in the project lifecycle in establishing testing conventions and streamlining the testing process so that all developers can efficiently write and execute tests.

The test case must be encoded. Not considering applicationsProgramCodeAs the only deliverables, the Test Cases, Documents (Javadoc and others) should be synchronized with the application code, and the test cases should be written at the beginning. If you cannot write test cases for a piece of code, you cannot understand enough to write the code itself. The latest test is useful. Unless the test is easy to run, otherwise they will not run. That is the important test that must be run automatically without interpreting the results-Here there must be a single sign of success or failure. Ant compiled with JUnit is usually used for automated testing. It is important to spend a small amount of time establishing test practices and simplifying the test process so that all developers can effectively write and execute code in the project lifecycle.

 

Especially in the case of Web applications, stress testing is vital. unsatisfactory performance is a serious risk in enterprise software development, and shocould be tackled early, through a proof of concept, while it isn't prohibitively expensive to modify the application's design.

Especially in Web applications ,. Stress testing is also important. Unsatisfactory performance is a serious problem in enterprise software development. It should be addressed in the early stages, through a conceptual verification, although modifying the application design is not a very expensive expense.

Testing J2EE applications involves extends different tests. We 've considered the following test strategies:

Testing a J2EE application involves many tests. The following test strategy is taken into account:

• Unit testing of classes (from all specified tural tiers) with JUnit. as we 've seen, the simple, easy-to-use, JUnit testing framework can be used as the basis of our testing strategy. unit Testing is usually the most important type of testing.

• JUnit unit test class (from all architecture layers ). As we can see, the simple and easy to use JUnit testing framework is used for our basic testing strategies. Unit Testing is usually the most important part of testing.

• Testing ejbs with remote interfaces using JUnit Test suites running in a client JVM.

• The remote test interface ejbs runs on a client JVM using the JUnit test suite.

• Testing ejbs with local interfaces using cactus (an open source framework built on JUnit that allows tests to be run within the application server ).

• Test the local interface ejbs with Cactus (an open-source framework built on JUnit and allows the test to run on the Application Server ).

• Unit testing of web-tier classes using JUnit and test implementations of servlet API interfaces suchHttpservletrequestAndHttpservletresponse. This enables web-tier classes to be tested outside the application server, making testing more convenient.

• Unit Tests on the web layer use JUnit tests to implement servlet APIs (such as httpservletrequest and httpservletresponse. This is where the web layer is tested outside the application server and is easier to test.

• Acceptance testing of the Web interface via "screen scraping" web tools such as httpunit.

• Web layer tests are carried out through "screen capture" web tools such as httpunit.

• Load and stress testing of database operations.

• Test the load and pressure of database operations.

• Load and stress testing of EJB component interfaces.

• Test the load and pressure of the EJB component interface.

• Load and stress testing of the Web interface.

• Test the load and pressure of web interfaces.

We 've also discussed the desirability of designing applications so that central functionality can be tested against ordinary Java classes, rather than harder-to-test J2EE components.

We also discussed the rationality of designing applications so that the central function can be tested to prevent common Java classes, rather than the difficulty of testing J2EE components.

Testing alone is not enough to ensure that code is bug free. other useful strategies include using assertions in application code and introducing the practice of regular code reviews. sound coding and design practices can do much to reduce the likelihood of bugs.

Independent testing does not ensure that the Code bug does not exist. Other available policies include using assertions in the Code and introducing regular code reviews. Good coding and design practices can reduce the possibility of bugs.

While the concepts discussed in this chapter apply whatever tools we use, I 've concentrated on free, simple tools. these are ubiquitous and widely understood, but there are more sophisticated than cial testing tools available, especially for Web applications, that are beyond the scope of this chapter.

The concepts discussed in this chapter apply to any tools we use. I just focus on free and simple tools. These are very common, but there are more complex commercial testing tools available, especially for Web applications, which are not covered in this Chapter.