Testing simple Semaphore usage in Java

Question

I have fields that manage information that multiple threads potentially work with. Access to these fields is critical so I instantiated a semaphore:

Semaphore semaphore = new Semaphore(1);

Every method tries to acquire the semaphore, essentially locking if none is available:

public void method()
{
    semaphore.acquire();
    doStruff();
    cleanUp()
}

//Other methods using the same basic layout as the method above.

public void cleanUp()
{
    //watch for state consistency and do some clean up
    semaphore.release();
} 

How would I go about testing the above knowing that:

• I don't want to use timed testing, using Thread.sleep(x) due to the inherent problems with that method such as the dependence on the clock and lack in trust of that method.
• I cannot use MultithreadedTC, at least not that I know of, since one thread will always be executing, hence, the metronome won't advance to the next tick.
• I don't want to modify existing code to add bits just for testing purposes. The code should stay clear of additions from testing.
• I would want something solid that I can run multiple times and use in regression testing.
• As I am not the only one using the code, it should be Java native and not use a scripting language such as ConAn.

The bit of code is small enough that I can, with a good certainty, say that it won't deadlock or the condition detailed above violated. However, a good test case could lend more weight to it and certainly add more confidence.

Answer 1

This is an example of a test-smell which arguably should motivate code change. The code is difficult to test because it's got synchronisation responsibilities mixed up in application logic responsibilities. Generally, it's very difficult to ensure that such code is acting correctly.

It would probably be best to extract the synchronisation related code into a separate class, which is testable in itself and use dependency injection to allow tests to mock that interface.

e.g.

public interface ResourceGuard<T> {
    void accessResource(Consumer<T> consumer);
}

public class ExclusiveResourceGuard<T> implements ResourceGuard<T> {
    private final T instance;
    private final Semaphore semaphore;

    public ExclusiveResourceGuard(final T instance) {
        this.instance = instance;
    }

    public void accessResource(Consumer<T> consumer) {
        semaphore.acquire();
        consumer.consume(instance);
        semaphore.release();
    }
}

You can now test this class by passing in a fake consumer which acts on test-scoped data and ensure that access is properly synchronised.

Then your production consumer class can have an injected resource guard...

public class StuffDoingClass {
    private final ResourceGuard<MyThing> myThing;

    public StuffDoingClass(final ResourceGuard<MyThing> theThing) {
        this.myThing = theThing;
    }

    public void method() {
        this.myThing.accessResource(this::doStuff);
    }

    private void doStuff(final MyThing theActualThing) {
        theActualThing.method(...);
    }
}

And now this class is testable with a simple enough mock of ResourceGuard.

From a design perspective it's also more difficult to access the resource mistakenly (without holding the lock). I know this answer goes against your 'no-code-change' mandate but in this particular case it seems very unlikely you can have all of your requirements met.

Answer 2

Take a look at JMeter.

It will allow you to fire up multiple instances of your code in many various ways. To ensure you are definitely seeing multi-threaded access, consider using more than one thread group in your JMeter test plan.

FYI: I find it useful when threading to synchronize on the actual object that is going to be updated. This allows you to control the updating of more than one variable in a controlled manner and is very self-documenting. It looks like this...

synchronize(variable) {

}

The above can appear in pretty much any method, even constructors.