CODEWITHSUNDEEP
javamavenunit-testingjunit
whileFalse
whileFalse

Reputation: 85

Testing multiple implementations in different maven modules?

Theoretical scenario:

Lets say you have a Core-Modul with many interfaces and some generic implementations using those interfaces but don't inherit from those interfaces along with multiple modules that are inheriting from those interfaces.

Something like this:

Core-Module

| - InterfaceA
| - InterfaceB
| - ...
| - InterfaceZ
| - impl
|     - GenericImplementationA
|     - GenericImplementationB

ModuleA

| - SpecificImplementationOfInterfaceA
| - SpecificImplementationOfInterfaceB
| - ...
| - SpecificImplementationOfInterfaceZ

...

ModuleZ

| - OtherSpecificImplementationOfInterfaceA
| - OtherSpecificImplementationOfInterfaceB
| - ...
| - OtherSpecificImplementationOfInterfaceZ

My question is now what would be the best way to write "generic" tests that are using the interfaces but are executed for every module with the specific implementation. Furthermore I want to write tests for those generic classes in the core module but I don't have a implementation of the interfaces that are used in those classes.

Some possible solutions I thought of are:

Downside of solution A is that you need so many redundant classes that are only inheriting from the generic test and passing the specific specific implementation.

Are there any good practice examples for this case?

Upvotes: 1

Views: 146

Answers (1)

GhostCat
GhostCat

Reputation: 140407

The main purpose of unit tests is to

  • test all aspects of the specific unit under test
  • help you to quickly identify/debug issues later on.

Coming from there: of course, one shouldn't get careless about unit test code quality, but unit tests are meant to be tailored/tight to the corresponding production class.

In other words: when A has some functionality X, then ATest should test that X. When you have some B extends A, then you want to unit test all things that B has "on top of A".

From that perspective, you rather look towards your second option. You see, when a test for one of your special modules fails, then you want to get to the issue as quickly as possible. You do not want to jump to some base test class first, to read 100 lines of code that have nothing to do with the fail in the subclass.

In other words: a test class should be as much self contained as possible, you are extremely cautious about using inheritance to avoid code duplication ...

Upvotes: 2

Related Questions