Category: Database, Data, Infrastructure, automation

The degree to which your tests are automated or not can be a huge factor in how successful your continuous testing strategy is.

If you have too many automated tests, or your tests are too complicated, then they may take too long to run.

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.

The rationale for this is simple: if you’re crunched for time at some point in the future (which of course, is always) - if your tests are prioritized, you can start with the highest priority tests and work down the list of priorities as you have time to do so.

This does require a baseline of some sort (a set of tests which remains static in terms of scope, the number and execution approach of the tests) - but once you have this, you should be able to take the individual and aggregated time for executing the tests and determine whether the performance of your application has improved, stayed the same, or gotten worse — and take the necessary actions as a result.

Related Articles