With JUnit, you can write a test class for any source class in your Java project. Even abstract classes, which, as you know, can’t be instantiated, but may have constructors for the benefit of “concrete” subclasses.
Of course the test class doesn’t have to be abstract like the corresponding class under test, and it probably shouldn’t be.
Whether we should test the abstract classes in a project, or use abstract classes at all, is a question that will depend on the particular project and the team’s preferences, but hopefully not any dogma.
I can think of a few circumstances under which it might be a good idea for an abstract class in the source folder to have a corresponding test class in the test folder. Specifically:
When the abstract class is meant to be used outside of its package or, in Java 9 and later, outside of its module.
When the abstract class has static units, which can then be invoked without instantiating any subclass.
When the abstract class has some awareness of its subclasses and can manage conversions between them.
When you want to be absolutely certain your project has 100% test coverage.
It’s nice to know that the option is available if you need it. But, depending on which integrated development environment (IDE) you use for Java, there might be some wrinkles you need to be aware of.
We’ll need an example of an abstract class. Postal codes, such as ZIP codes, are a good example, as I explained in an earlier article. I also explained how to test an abstract class in Eclipse.
For this article, I will focus on the two other major Java IDEs, NetBeans and IntelliJ IDEA (generally known as just “IntelliJ”).

#abstract-class #intellij #netbeans #junit #java