At Brightec code quality is a top priority. Much of our business revolves around selling great code.
Code quality can mean lots of different things.
It also means we write tests for our code.
Tests prove that the code you wrote actually does as you intended. This seems counter-intuitive because surely you wrote the code, so it does do what you intended. I tend to agree with this statement but with the caveat that we all make mistakes, all the time. Writing tests helps you to spot the mistakes you made. You get to fix them before they even get committed and shipped.
There a few other side effects to testing which are also beneficial.
Given When Then (GWT) is an approach adopted by many teams. It’s a style of writing tests which lays out a framework for what a test should look like.
Given - This is where you define the state of your application up to this point. You provide any data or context. Usually, this involves setting up mocks or stubbing methods.
When - This is the part of your application you are testing. Usually, this is a method call.
Then - This is where you verify a particular behaviour or outcome. What did you expect to happen?
Here you can see a simple method which multiplies a given number by 2. In the test shown, we have a given of x = 1. We have a when of multiplyBy2(). A then of result = 2.
In summary, given that we have an integer of 1, when we multiply it by 2, then we expect to get 2.
This is a nonsense example, but it demonstrates the GWT structure.
Having a clear format to these tests can help any readers of your code understand your approach. It lays out what you think you're given, when and then are. Enabling the reader to challenge those choices.
It also helps you to get into the flow of this pattern.
The name of your test method appears in your results. So it's important that it gives a clear indication of what you are testing. Therefore, we find it helpful to write out the given, when and then.
We use two underscores to separate the sections of GWT. One underscore can be used to separate words within a section. This can, in complex cases, lead to long test names, so you may have to adopt abbreviations. But long test names are better than ambiguous test names.
Within the method body, we use comments to separate the sections of GWT. We use capitalized words to offer a distinction between these titles and any other comments we may need.
We ensure that there is clear space between the sections of GWT.
To enable you to check a result within the then section of your test, you can add a variable to capture it. This allows you to keep clear separation between when and then.
Many testing frameworks, like JUnit, enable you to add setup code to your test class. This code gets run before the start of every test. Due to the nature of it, this is inherently implied to be part of your given.
Common sense, and applying good practice is needed to decide what goes in the @Before. Since anything within your @Before, may not be immediately obvious to the reader of your test.
We generally only initialize mocks within our @Before. We outline mock behaviours within the test body. We also create the class under test within @Before.
Like @Before, @After, or similar, allows you to add code which runs after every test. This is generally the place you do any cleanup, which if not done, would affect the result of the following test. This sits outside the GWT pattern.
Sometimes there is nothing to go in your given section. In these cases we still have our given section in the test name and method, we just comment // nothing.
In many tests, you want to verify that a particular method gets called. You don’t need that method to actually run, you just want to check that it would. In this case, you want to stub that method.
Stubs don’t fall within the GWT pattern, as they are simply an efficiency measure. We put them at the top of our test method in a separate section.
It can be tricky to handle callbacks within tests. It can be even harder to fit them into GWT pattern.
We would typically describe the flow of doWork() as:
We call doWork(), then when the network request is successful we expect the cache to get updated.
Instead, if you think about it as:
Given that the network is going to be successful what do I then expect this class to do.
This subtle change can help us to fit this kind of test nicely into GWT.
Practically, with JUnit, this can be hard to write. We are tempted to use verify, in combination with an ArgumentCaptor, to reply to the callback. Instead, if you use doAnswer, as shown above, it sits nicely within the given section.
Using GWT at Brightec has helped us to structure our tests, write single responsibility tests and improve our test coverage. We no longer write bloated tests which are hard to read and understand.
GWT is not the “best” way of writing tests, but it can be a helpful approach to improving your tests.
Search over 200 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!