The testing during the Construction & Assembly phase refers to the testing conducted by the development team and includes Functional, Unit and Performance testing. This is distinct from the testing performed by the Testing and Certification Office (TCO) in the Independent Verification phase that focuses primarily on Functional testing.

During the Construction & Assembly phase, the focus will initially be on Functional and Unit testing, and shift to Performance testing as the code base matures. This is not to say that performance testing should be ignored until the coding is near complete. In fact, if performance is a critical requirement, the subsystem or functional area should be tested as soon as possible to verify the design will meet the performance requirements.

Functional tests focus on the functionality of a service, sub-system or logical area of code. For example, testing the Business Services of an application would be a functional test at the service level. Another example would be testing the Data Access Objects in the system. Both tests would verify that using the API provided resulted in a particular result. Functional tests are often the first tests written during development to test the interaction of a boundary class with the system it is in communication with, or a service the system is providing. Because tests can be somewhat fragile and difficult to maintain, a recommended approach is to write functional tests for the "happy" and common paths, aligning the tests with Use Cases and code. For the corner cases, rely on the Unit Tests to get complete test coverage. With Functional and Unit tests, a balance must be reached on the level of test coverage and the cost to create and maintain the tests.

Unit Tests focus on individual classes and "mock" any interactions with outside systems. These tests should be written as the class is written and executed with each build. In many minds, a class is not complete until there is a corresponding Unit Test class that has 100% code coverage of the class being tested, but each team can set the requirements as appropriate. Using jUnit, Ant and EMMA, tests can be automated and builds can produce html reports of test success and amount of code coverage. Unit Tests are not fragile and are key to being able to regression test a project to ensure no side effects arrive from a bug fix or code change.

Performance Tests assure that the application meets the defined performance requirements, which should be clearly defined in the supplemental specification. Depending on the type of performance being measured, the appropriate tool should be selected. For example, JMeter is a tool designed to load test an application. The rational suite of tools also provides different testing options. The Architecture Office also has a Code Lab to provide input to development teams regarding this subject. You may direct questions to them via the Code Lab email.