01 Apr
Unit Testing is hard.
First, you have to think about what you want to test, how to test it, and then write code for it.
While writing code for your test cases, you also have to stick to patterns and clean code conventions (and understand them, first), if you want to understand your code in a few months (or others should understand and work with your unit tests).
And after you’ve accomplished these first two parts, the actual work starts. After every change performed at your tested code, you have to manually adapt all affected unit tests (which means constant maintenance and reworking).
Here are three ways that I use every day to make unit testing easier for me. They’re based and proofed on my experience from writing more than 1.000 test cases as a c# test automation expert (you can read about my other learnings in the follwing post).
Think, Specify, Code.
The value of writing tests is often difficult to grasp.
You write your code, and then, you have to think about what you’ve done again, in order to come up with ways to test your implemented functionality (that is already there, anyways).
That’s why I usually use a different approach.
- I first try to envision the system I want to implement as detailed as possible, without actually writing a single line of code.
- In a second step, I write down my thoughts in a structured manner. I personally like to write . But even just using pen and paper should already do the trick.
- Only in a third step, I try to translate my specification into actual code.
You can read more about these three steps in the following post: “Try This For a Week And Speed Up Your Coding Productivity 10x”.
Bonus: with the right tools, you can even automate the coding part, by generating test code from high-level specifications such as equivalence class definitions. (See also “Forget Writing Unit Tests. Try This Instead.“)
Create a Test Gate.
Maintaining unit tests so that they represent up to date requirements is hard. Make a single change in your source code, and chances are high that you have to adapt a whole bunch of test cases, because they either (i) do not pass any more, because the represented requirements have changed, or (ii) do not compile at all (due to changes in the code structure). But as soon as you don’t keep your tests up to date, they lose any value at all.
So, how can you make test maintenance easier?
By simply enforcing yourself to only push code if every single unit test in your project passes.
This is what I call a Test Gate. You can implement this in most build tools, and what it basically does is run your test suite after each checkin, and only allow a push of the changes if the result of each test case is positive.
Use consistent Naming + Code Patterns.
But even if you are forced to keeping your test cases up to date, one problem still remains: you have to actually udpate your test cases (most often a whole bunch of them) every time you make a change to your source code.
That’s where clean code comes into play: By structuring your code (and that includes not just your test case content, but e.g. also classes that contain tests, and folders that contain test classes) in a common way that is optimized for readability and adaptability, you can minimize the cognitive effort that is required to actually change something. In other words: Immediately knowing where to change something spares you a lot of time when you actually have to change something (sounds logical, right?).
In my experience, there are two efficient methods to achieve that. Each developer that does unit tests should know them by heart:
- The AAA pattern. This pattern defines how you structure your code in every single test. You can read more about this pattern (and see particular examples) here.
- A naming strategy. This means that you need a common way to encrypt details about your test case into its (i) method name (ii) class name, and (iii) name of the folder hierarchy that the corresponding class lies in. You can read more about particular naming strategies in part 6 of this ebooks series, or the following medium post: Unit Test Naming Conventions.
Pro Tip: if you are using a good test case generation tool, the generated code usually already sticks to all these clean code patterns – so you don’t ever have to worry about remembering every little detail about them.
So, do you want to go these three ways as well, and make Unit Testing easier for you?
If you did already, let me know about your experiences in the comments section below!
written by Daniel Lehner
Daniel Lehner is a PhD student at the Johannes Keppler University in Linz, Austria. His research focus is on traceability of software information between different stages in the development cycle. During his master studies in Business Informatics at the Vienna University of Technology, Daniel worked as a consultant in the area of software quality assurance.
Information
Daniel Lehner