5

I'm currently trying to add TDD on my workflow. I fail to create tests where I can easily test a library that requires remote connections.

More precise, my program uses snmp4j library. Currently I'm working with 1 release behind due to I don't know what's the impact of the new API release on my code. So I read that implementing a battery of tests based on what I use from the library I can have a better overview of the impact if I upgrade to the new version. So I have the following question

  • I need to get an snmp response based on a request. Ideally would be that I have control over the machine and I know what to ask and what to expect ... but what if that remote machine is down, has network connectivity problems or doesn't exist? Should I create a SNMP agent listening on localhost and have control over which OID I ask and which responses I give? I rely heavy on the type of responses from the OIDs (being Integer32, Gauge32 etc) not the values I receive.

The response doesn't have to be so concrete, actually I would like to read more about this kind of scenarios where you need to test network connectivity through an API.

Improve this question
5
  • 1
    As soon as external components are involved, it is not unit testing, but integration testing.
    – Bart van Ingen Schenau
    Commented Dec 31, 2014 at 14:38
  • Yes, you should mock out network clients
    – raptortech97
    Commented Dec 31, 2014 at 14:38
  • @BartvanIngenSchenau but in my case is just a few methods I use, the problem is few of them requires an external source replying. Still considered integration?
    – user50236
    Commented Dec 31, 2014 at 14:43
  • @jmolinaso: If the external replies weren't needed it could be argued both ways. The need for replies from an external source puts it squarely in integration testing. But don't let that stop you.
    – Bart van Ingen Schenau
    Commented Dec 31, 2014 at 14:46
  • I think it's important to clarify that just because this is an integration test rather than a unit test doesn't mean it isn't appropriate for TDD. The idea that TDD requires isolation is a myth; see stephenwalther.com/archive/2009/04/11/…
    – Jules
    Commented Jan 1, 2015 at 10:52

1 Answer 1

Reset to default
4

In their book Growing Object-Oriented Software, Guided by Tests, Steve Freeman and Nat Pryce tackle this very issue. I do recommend that as a worthy read, since it's full of interesting examples and I'll probably just misquote, anyway.

Rephrasing, they argue that instead of mocking the external API you have no control over, you should create a layer of adapter objects. That way you can translate the data to your application's terms and distance the third party code from yours.

I rely heavy on the type of responses from the OIDs (being Integer32, Gauge32 etc) not the values I receive.

Based on what you said, that could be a helpful pattern to adapt to.

However, the authors also state that this pattern may not be applicable if your application relies on value types. So in the end it boils down to: it depends. Abstracting value types may not make sense in this particular case, but if it does, here's an option worth considering.

Improve this answer
2
  • Give you the right answer, not only because you are the only one, you also refer to something I can read to improve ;-)
    – user50236
    Commented Apr 3, 2015 at 7:24
  • 1
    @husker I'm glad you did that, thank you! Just be sure to undo your action and downvote my answer once you've gotten the book and noticed that I have misunderstood the whole concept. The section I was referring is in chapter 8, Building on Third-Party Code.
    – sankari
    Commented Apr 3, 2015 at 21:00

Your Answer

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