Choosing an Edition for Testing

Choosing which edition to use for testing is much easier than choosing an edition for development. In short, your test environment should match the production environment as closely possible. Of course that's a bit of a wide-reaching statement because different kinds of testing will require different kinds of environments.

Running Unit Tests

In general, unit tests will be run by individual developers on their workstation, which means that the edition used for development will be the one used to run unit tests. However, it's often useful to run the unit tests as part of some automated nightly testing procedure. In this case these automated tests should be run on the edition that you intend to use for production. This is especially useful if you're developing on a different edition because it enables you to catch any incompatibilities between editions as soon as possible.

Running Integration Tests

When you have multiple developers working on a project it's important to run integration tests in addition to unit tests. Although a unit test typically exercises one small piece of functionality, integration tests are necessary to ensure that all of the components link together correctly. Thus, they often test entire use cases from end to end.

To ensure that the test results are as accurate as possible, you should make certain that the edition of 10g AS used to run integration tests is the same edition that you'll use for production. This is often a requirement anyway because some of the components requiring testing may only be available on the production edition.

Running Performance Tests

Running performance tests is an important part of building an application and you should run them frequently. Indeed, you should run the performance tests as often as you run integration tests. Many teams will leave performance testing until the end of a project but this is not the best approach. By running tests regularly, say daily, any noticeable differences in performance can be attributed to work that was carried out during that day's development.

You'll almost certainly want to use the same edition of 10g AS for performance testing that you will for production in order to ensure that your performance figures are as accurate as possible. It's also important to try to use the same (or equivalent) hardware so that you can measure performance in absolute terms. For example, if you're building an application for a client, part of the acceptance criteria for the application may be a guarantee that no page takes longer than three seconds to load for a broadband user . To ensure that you can hit this goal in production, you'll need to test on your production servers or at least a similar configuration. Of course, if you can easily hit your goals on less powerful machines, then there's a good chance you'll be able to hit them in production. However you should take great care to ensure that other factors such as clustering or network overhead will not affect the performance of your application.

It's also important to consider a typical workload when testing. In general, you want to test your application using a workload that's more demanding than you expect the application will generally experience. In that way you can get a feel for how the application will perform when it's really being pushed . Avoid the temptation to just test a particular micro-feature; instead, try to test the performance of whole use cases and run different use cases in parallel. In this way you can mimic more closely a real world workload, which is especially useful in highlighting any spurious problems with performance or threading.

Environmental Considerations

When configuring the development and test environments it's important to try and avoid overlap. If developers are using a different edition of 10g AS, then it's often useful to give them access to a server running the production edition. You should, however, avoid the temptation to use the same server for testing. The testing should be carried out on the same configuration each time. By allowing developers direct access to the testing server it becomes very difficult to ensure that this happens. Problems can arise when a developer makes a change in the test environment that other team members are unaware of. The test environment should match the production environment as closely as possible and as such once it's set up there should be no need to make changes. Any changes you do make may result in code that works in the test environment but not in the production environment.