Unit testing and both parts of the contract

[Miguel Casal Guillán]

Lately I'm thinking about my TDD process and the distinction between unit and integration tests.

In an example I'm currently developing I have a small CLI class whose only responsibilities are parsing command line arguments and outputting results. It has a collaborator object that encapsulates all the related operations with consuming a web service.

With the CLI tests I've defined the outside behaviour of the collaborator through expectations (methods, return values, exceptions, etc.). Now that I've finished I will start creating the tests for the consumer. This new piece of the system has to respect the behaviour expected by its clients, but how can I be sure if the CLI class is tested against mocks and not real implementations? Is the purpose of the integration tests? AFAIK they are necessary with third party code we don't control and on the other hand the acceptance tests can't check every possible branch...

Note: is Python code.

Many thanks!

[Daniel Wellman]

Hi Miguel,

Like you said, you could use acceptance tests to ensure that your CLI talks correctly with your web service consumer - but if you have many options, then you'd probably end up with a lot of these which could be brittle

Here are some questions I wondered when I read your description of your problem:

- How many options does your web service have?  Is the program you're designing attempting to expose all the options of the client, or simplifying?  If there are many options, could you simplify the options you expose to reduce the risk of your program breaking?

- How long do you expect to be working on this application?  If you are providing a CLI front end to an already built web service, can you get away with more tests that are nearly end-to-end?

- If you are worried about the CLI providing incompatible inputs to the web services client, is there a way to change the interface you provide to the CLI so it's less likely to break?

- Could you move some of the command-line option specification into domain objects so that the CLI does even less?

Regarding your question about the purpose of integration tests, in your scenario I'd probably have the code that calls the third-party web service use the real service -- or use a fake server that uses HTTP to simulate it?  If you don't control the web service itself, could you give that team some consumer-driven contract tests (http://martinfowler.com/articles/consumerDrivenContracts.html) to help them know if they accidentally (or intentionally) break your client?

Cheers,

Dan

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Israel Fonseca]

For every expectation of the WSCollaborator in your cli test write an integration test for it. By integration I mean an test that checks if your WSCollaborator indeed does the right job with the external system. The first kind of test is the collaborator test, the second one the contract test. This is the approach proposed by JBrains in his talk about integrated tests are a scam.

[Miguel Casal Guillán]

Excuse me for replying that late, I've been a bit busy with other things.

Thank you for your detailed comments and insights. I pushed to GitHub [1] what I've done so far (very little). It's a simple context like any other for practicing with Python and TDD, nothing fancy :) For now I don't think I need integration tests. Maybe when the server is implemented.

[1] https://github.com/miquecg/meteoservice/tree/feature/tomorrow-temperature-in-vigo

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.