在两个不同的 JVM 中测试通信软件

Question

I've written a module in Java that communicates over a socket. I'd like to write a unit test that tests sending and receiving.

To really test the system, I'd like to put the sender in one JVM and the receiver in another and test them together.

From what I've read here and in various blog posts, this isn't really unit testing, it's integration testing. Ok, fine, but I still want it to be part of the build process.

Is there an official, recommended way to launch a second JVM from within a Junit test case? If not, is there another standard testing framework that is designed for this?

Answer 1

I use some shell scripts in my build. Not sure how to verify the results, but whatever runs Maven in your automated build could check some output file or something. Under build/plugins I do this:

<plugin>
    <artifactId>exec-maven-plugin</artifactId>
    <groupId>org.codehaus.mojo</groupId>
    <version>1.3.2</version>
    <executions>
        <execution>
            <id>Validate English and Term Customization</id>
            <phase>test</phase>
            <goals><goal>exec</goal></goals>
            <configuration>
                <executable>${project.basedir}/validate.sh</executable>
                <workingDirectory>${project.basedir}</workingDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>

You are essentially going to have to create a separate project to deploy and test your code over the network. This is going to be a pain in many ways. You might consider "integration testing" and "pain in many ways" to be somewhat synonymous.

Keeping integration tests up to date is probably the world's best inspiration for doing better unit testing. I'd still try to Unit-Test as well as possible.

• Put your unit test in a different package from the code you are testing to assure you aren't accessing anything package-scoped.
• Every time something breaks on 2 servers, try very hard to write a unit test that fails in your build before fixing the bug, then verify that it passes once fixed.
• Thorough unit testing is usually possible if you're willing to stub out enough things. In my experience, it's been easier to undergo a Herculean effort to stub things out, than it is to have a whole separate (yet totally dependent) project to do unit testing that will break your build if it doesn't work.
• Could you find those bugs with a code-inspection tool (either off-the shelf, or a grep/sed script, or a custom program) instead of an integration test? I'd much rather see you run that from your build.

Even if you have a whole separate integration testing project that's part of your build, you might want to run that once/day once/week instead of every check-in.