With the increasing acceptance of agile software development in practice, testing practices must also be adapted stay suitable for this trend.
Reduced release cycles and constantly changing requirements pose huge challenges on current unit testing practices.
In this article, you’ll get three smart strategies to cope with these challenges in your daily unit testing.
To adapt the speed of testing to the speed of development, testing should be automated as soon as possible.
This can e.g. be achieved via Test-Driven Development (TDD), in which the unit test is even written before the actual code for specific functionality.
However, each test requires a certain conceptualization phase, in which the relevant information to be tested is defined through a creative process of the tester/developer. It is often useful to validate and adapt this concept by executing test cases manually, before writing (which is of course not possible in TDD). Even if test cases are executed manually for the first time, it is important to automate test case execution as soon as possible. This reduces the required time for re-execution to an extent that makes it feasible to re-run tests before each deployment. If this is not the case, you don’t know whether your deployment actually breaks existing functionality!
Whereas methods such as Equivalence Class Partitioning or Boundary Value analysis can help a lot in this conceptualization phase mentioned above, the translation of a test concept into unit test code is usually still done manually.
To achieve automation as soon as possible, the process to come from a conceptual description of tests to unit test code that can be executed with a single click must be automated as much as possible. The higher the automation level here, the less time is required for each unit test.
But how can we automate writing code?
First of all, by structured specification. If you define your test cases in a format that can be understood by a computer, this computer can usually automatically generate code for you, by mapping specific keywords to code templates. Code generators can use a whole test case definition as input to auto-generate boilerplate code for your unit tests. E.g. the whole idea of Behavior-Driven Development (BDD) is based on this generator concept. Read more about this in the following e-book: TODO: referenz zu ebook “The Next Generation of Programming Languages” – das hab ich leider auf der Homepage nirgends gefunden.
A second technique is to use Artificial Intelligence to even support automation in the conceptionalization phase based on information re-use. Machine Learning techniques can be used to e.g. choose test case inputs from equivalence classes or calculate expected test outputs. Fuzzing or heuristic search techniques can be used to optimize test suites over time.
Although the automation potential of the techniques mentioned above help a lot to find initial test cases, automation can be further improved over time by reusing information that was already defined in the past.
This can e.g. be achieved with a clean project structure that enables modularity (learn more about structuring your unit test project in part 6 of this ebook series: https://www.devmate.software/ebooks ).
More advanced techniques even allow to reuse information that you already defined somewhere else in your project. One example here is a recommender system that suggests test cases using similarities between code units. Sounds like sci-fi? Such recommender systems are usually already implemented in state of the art unit test automation tools such as devmate TODO: link zu devmate.
The #1 thing that you know for sure in an agile software project is that things will change in the future. However, every time you adapt your code, you also have to adapt the corresponding unit tests. That’s why you should take care of this from the beginning. Try to write code that makes sure that every adaptation takes as less time as possible.
Find good naming strategies (https://www.devmate.software/a-checklist-for-assessing-the-quality-of-your-unit-tests/ ), stick to best practices (https://www.devmate.software/the-aaa-test-pattern-explaind-with-c-and-nunit/ ) and define a test gate to force you to keep your unit tests up to date.
Of course, all automation techniques from above help here as well.
What are your experiences with agile software development, and agile unit testing in particular?
Let me know in the comments section below!
When you visit any web site, it may store or retrieve information on your browser, mostly in the form of cookies. Control your personal Cookie Services here.