While You’re Coding

The most obvious place to start developing your automated testing capability is while the product code is being written in the first place.

Retrofitting unit tests to legacy code is problematic. If you’re in a situation where code already exists, you may wish to skip this step in favour of tests at some other layer of your technology stack. But where possible to do so, adding unit tests to your testing strategy is going to pay dividends in the long term – providing your team with increased confidence any time they need to add to or change their code.

If the development team is agreeable, following a TDD (Test Driven Development) approach is pretty much the holy grail of this level of testing. With a TDD approach, your developers will write tests BEFORE the code is produced, helping to guide both the design and the development of your solution, and providing you with the best possible degree of unit test coverage in the process. This is the ultimate win, for all concerned!

Integration Testing

Sometimes, unit testing won’t be feasible or appropriate though, depending on the technology and architectural choices that have been selected for your project or product. The next best thing is to follow more of an integration testing-based approach, focusing on the areas of your project with the highest levels of integration risk.

Precisely how you approach integration testing will depend on your product architecture. In a classic three-tier (database, business logic, user interface) arrangement, you need to focus on integration between the business logic and database layer, to ensure that correct data is stored or retrieved from your database when specific transactions are performed. For bonus points, start thinking about performance requirements here also, since the transaction times will have some bearing on the success of your project.

#devops #automation #software testing #test automation #continuous testing