1

In order to create a very testable codebase, I abstracted away a certain external dependency. To be precise, this dependency is actually implemented by a vendor SDK and it communicates directly with a hardware. As such, this is the interface:

public interface IHardware
{
    void Send(IMessage message);

    event EventHandler<MessageEventArgs> OnMessage;
}

(The communication with the hardware is fully assyncronous)

As soon as this is initialized, events may be raised by the hardware (through the the OnMessage event). Client code can send messages any time, and possible responses will be received in the form of events.

Now, this very simple interface needs to be implemented; The implementation is just a delegation to the actual SDK class. The problem is this: how I write tests to provoke the proper implementation?

9
  • 2
    You can't test this in any useful sense of the word. It would require simulating the hardware in the tests. That's a non-trivial amount of work, you may implement it wrong, and worse yet you'll be prone to making the same incorrect assumptions about how it works that'll lead to bugs in the real code; so the tests may pass and the code would still be wrong.
    – Doval
    Apr 18, 2015 at 18:33
  • 4
    @Doval Doesn't that argument apply to any mock of a non-trivial dependency? That's why you need integration/acceptance testing in addition to your typical unit tests that tell the mock "expect to be sent message X, then fire events A and B".
    – Ixrec
    Apr 18, 2015 at 18:47
  • @Doval, do you think that this means "You can't do TDD on this kind of boundary"? I can accept that, but it seems to contradict what the TDD community believes in. Apr 18, 2015 at 22:39
  • 1
    Test-Driven Development is really about Test-Driven Design. Are you designing the SDK? Apr 20, 2015 at 15:55
  • 2
    Those are just words anyway. The point is that some programmers think of these as programming techniques, in the same vein as a for loop, and they're really not that. I asked if you were designing the SDK because if it's already written, it's not Test-First-Design (one of the tenets of TDD) by definition. May 13, 2015 at 15:23

2 Answers 2

5

As you noticed, the TDD mantra of only writing code in response to a failing (unit) test starts to break down when you approach a system boundary where you need to integrate with hardware or third-party code.

You started out right by defining an abstraction layer over the SDK (in the form of the IHardware interface) and writing your code against that interface.

As it is unlikely that the IHardware implementation can be subjected to automatic unit tests in a meaningful way, you may have to let the ideal of TDD go for that part of the project. However, not all is lost:

  1. With a bit of luck, the adaptation layer is simple enough that it can be verified by reviewing the code
  2. The SDK you are wrapping is likely to be well tested already
  3. You can still test the combination of SDK and adaptation layer with higher-level tests, such as integration tests and acceptance tests. These tests you will need anyway to prove the entire system works correctly.
1
3

Abstracting away the 3rd party dependency like you did does not only benefit testing, as it also makes your code more robust against changes in the dependency (by effectively wrapping it/creating your own adapter).

Testing that the real 3rd party product does what you think it does when receiving commands from your code might not be possible in the context of unit testing. However, what you can do is to verify that your Adapter works as you expect it to. Sending commands when you expect it to and acts accordingly when messages are received.

Example:

    [TestMethod]
    public void shutdown_on_receiving_off_signal() {
        HardwareMock mock = new HardwareMock(); //implements IHardware, and replaces the 3PP in your tests.
        ThirdPartyAdapter adapter = new ThirdPartyAdapter(mock);
        adapter.shutdown(); //send shutdown command  to the IHardware impl.
        AssertMockReceived(OFF_SIGNAL);
    }

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.