|
Web services and SOA bring in a very important, but understated trend to the IT world: complexity. It is creeping up from the application code out to the architecture. Services are reused, transactions are orchestrated at the message layer, and runtime policies manipulate meta-data content in messages and sometimes route them them accordingly. These are all factors where we see complexity manifest itself outside of the individual application. This trend reinforces "architecture first" development paradigms where the system is created first, and application code second.
Integration has been a major source of problems and will continue to be so when left till the end of the development cycle. Therefore, it is important to start with a development environment that is as close to the production environment as possible, with builds created at a regular (typically nightly) basis and deployed, integrated into the development system. When this is achieved, it becomes possible to build and maintain regression test cases against the system so the tests can be created, grown and maintained with the system as it evolves. Such tests would have the capacity to be as realistic to the real use case scenarios as possible, because they are running against a pre-deployment system that is close to the final product, which makes them even more powerful in making sure bugs are not introduced and for functional correctness to be maintained throughout the development cycle.
A major challenge to achieving this process is isolating an application in development within an environmental context that resembles the product context. Stubbing and emulation is needed here, which requires some initial work to be done. However, such initial efforts pay off in the long term because you end up with an agile, continuous process where changes can be made and builds are immediately tested and verified. The system actually becomes testable, which is an important trait before it is deployed. Only that approach makes the process predictable and controlled so that you can move ahead with the project knowing that there is minimized room for surprises at the end.
So in summary, integration testing should be done early, and side by side with the other kinds of testing (e.g. unit testing). If the application is not testable with such an approach then something is wrong. An investment should be made in the beginning to make it testable. Development teams would find themselves wasting a great amount of time with manual build and deploy activities if the system is not integration-testable, and that would only get worse when that happens towards the end of the project.
|
