This post belongs to the How to create Lean Test Automation Architecture for Web using Java series. If you didn’t see the previous posts, please check them out!
It is a simple approach to set up common initialization and cleanup in your tests. We commonly categorize it as a Testing pattern.
The problem we are trying to solve here is the reuse of common behaviors across test classes avoiding coding duplication and centralizing these actions at one point.
The application of a Base test class, in OO programming languages, is applied by the use of inheritance.
Let’s say you need to open the browser as a pre-condition and close it as a postcondition. Any test you create will have it, creating a code duplication.
Can you see in both test classes we have:
Both annotations were provided by JUnit 5.
@BeforeAll execute the code inside the method before all the
@Test methods before being executed.
@AfterAll execute the code inside the method after all the
@Test methods being executed.
As you can see we are duplication code, and it is a bad practice that neither does not scale your test not add less maintenance to it.
The class below is Base test class implementation. You can notice the following:
As you can see we are avoiding the code duplication and adding the pre and post condition in a single class, so it will be a single point of change.
I have removed, in both tests, the pre and post condition, bu they will continue to run because I’m extending the test class by the
BaseWeb (the Base Test Class).
How it will be executed automatically?
Because we are using an annotation provided by JUnit 5. So, before the
@Test can run the pre-condition will be executed because it’s inherited from the
BaseWeb class. The same will happens with the postcondition.
You cannot instantiate an abstract class. So, we can declare methods with or without implementation and define fields that are not static and final. So abstract classes will provide:
We will not use abstract methods as, per definition, we must implement in the parent class. We are going to write abstract methods with implementation to be able to override them if you want, giving you more flexibility.
As you can see I used the pre and postcondition approach from JUnit 5. You can take advantage of these features to write a clean and maintainable test.
You can learn the pre and post conditions implementations from:
If do you need, by any change, not execute the pre or postcondition (in the scenario you need to use the Base Test Class) you can simply override the method removing the
super reference, making it empty or adding your custom implementation just for that test.
But bear in mind if you need to do it in many test classes you might end up with a new Base Test Class, and it’s ok. Personally I never saw different ones for a web test approach, but I’m using different ones for the API tests.