I have a very simple `Check`class which has a blocking `waitForCondition()` method. This method is blocking. I want to create some unit tests for this method. First, the method should return when the condition is met. Second, the method should return when it is interrupted. 

Internally the `Check` class has an `ArrayBlockingQueue` and calls its `take()` method, so my test is really about having coded the logic for the condition correctly (as it should be).
In the application, data for the `Check` class is fed by another thread via an `InputData` method. The `InputData` method executes the logic on incoming data and places a dummy object in the ArrayBlockingQueue when the condition is met. This should cause `waitForCondition()` to return.

So my first thought is I can test the `InputData` by mocking and check to see the dummy object is added to the queue when the condition is met. This would require changing the design of the class, since the queue is a private data member (unless it is possible to mock private data). Instead of `InputData` adding directly to the queue when the condition is met, it would have to call something which could be mocked.

But then there is the problem of checking the `waitForCondition()` methods themselves, given that `InputData` is functioning correctly. It's really simply code:

```
try {
        myArrayBlockingQueue.take();
        return true;
    } catch (InterruptedException ex) {
        return false;
    }

```

So I'm wondering if it's worth the imagined trouble: a test which creates another thread with a `Check`, calls its `waitForCondition()`, then returns something when it's done. Perhaps, using an Executor service. The fuzzy part is how to synchronize the `assertTrue(...)`. I found this [article on asynchronous testing](http://etutorials.org/Programming/Java+extreme+programming/Chapter+4.+JUnit/4.15+Testing+Asynchronous+Methods/) which looks like it might do the trick. 

Summary of question:

1. Should I change the design to test the logic in `InputData()` and if so, how?
2. Should I leave out the test of `waitForCondition()` as long as `InputData()` is tested?
3. Or is it better to just do what needs to be done (a somewhat complicated unit test) and test `waitForCondition()` directly?