如何在具有不同依赖关系的模块之间重复一组测试？

Question

I'm starting a project where a "core" module will define a set of common interfaces and other modules implement those interfaces using different libraries on the back end. It's very similar to SLF4J, where the API module describes all the operations you can use and the binding modules implement those operations in various logging frameworks like Log4j, java.util logging, and Logback. To use it, you depend on the API module and one of the binding modules, and you only ever interact with the API.

My problem lies in testing. Since the API expresses all possible operations and every binding module should behave the same way, I want to write one set of tests that describes the expected behavior and run the same tests against every binding module. How should I organize things to get this to work without a lot of repeated effort?

This is a Java project with plenty of Groovy, and I plan to build it with Gradle.

Answer 1

i've done this sort of thing with JUnit before. what i did was define a set of abstract test classes with all the logic:

public abstract AbstractTestBase {
    protected abstract CommonInterface getInstance(); //for subclasses to implement

    @Test
    public void testSomething() {
       CommonInterface instance = getInstance();
       //test instance
    }
}

and then concrete subclasses are usually just tiny classes that return the concrete implementation to be tested:

public class TestSomeImplementation extends AbstractTestBase {
    protected CommonInterface getInstance() {
        return new SomeImplementation();
    }
}

on some i've added specific tests for specific implementations, but in your case i understand you wont need to.

Answer 2

It depends on the binding mechanism. If multiple bindings can co-exist, you can tackle the problem on the test level, by writing a data-driven test that runs the same test class/method for each binding. (Details on how to achieve this depend on the test framework in use.) If bindings cannot co-exist, you can tackle the problem on the build level. For example, you could create ten Test tasks which would be configured identically except for the implementation Jar on their class path.