2

I totally believe in not repeating yourself in production code. I've accepted the idea that you shouldn't repeat yourself within test code. But what happens when you have production services that would simplify test code?

Let me pose an example. We have a service that accesses the Doohickey API. The Doohickey API is complex, by necessity, and we have a bunch of code to simplify it for our needs.

Now I need to write some automated tests for our service. My tests need to set up data in the service and it would be really handy to reuse that facade. But then I get into an argument with myself, that goes roughly like this:

"If you introduce a bug in the Facade, the test might not show it."

"But, if you just take a copy, then when Dohickey Inc upgrade their API, you need to make the change in two places."

"True, but maybe that's a good thing. We can upgrade production code first, manage test data using the old, known, still-supported API and test the new version thoroughly."

And then I think maybe I'm overthinking the problem. Does anyone have experience with this kind of issue? If so, which way did you go, and did you regret it at all later?

Edit: Early comments suggest a more specific example is required.

Say I have a service that can create a product AND create an order. I have the following test to write ...

Given that product X exists
When customer Y orders product X
Then an order should exist for customer Y, including only product X

For the "When" part of this, I contact my service, which uses a facade around the Dohickey Purchasing API to create the order.

The "Given" and "Then" steps should create a product and get an order, but they shouldn't go through the service to do so. Perhaps my service doesn't have that functionality, and if it does then I will test it elsewhere.

BUT the facade that lives within the service would make the test code much simpler. So should I reference the production code and use it or copy / rewrite the facade?

  • 1
    as far as I can tell, you need dedicated tests focused on verifying Facade; other tests would better use Facade assuming that it is okay. IIRC there was a similar question here already – gnat Mar 6 '14 at 12:09
  • @gnat: I found a few related, but couldn't find a duplicate. Or at least nothing where the answers addressed any of my concerns. Happy to be proved wrong though. – pdr Mar 6 '14 at 12:16
  • Perhaps I misunderstand your question, but when you mock an interface, there is an inherent level of duplication and if the interface changes, both the provider, user(s) and mocks need to be updated. – Bart van Ingen Schenau Mar 6 '14 at 12:23
  • @BartvanIngenSchenau: Would it help if I was clearer that I mean integration tests, rather than unit tests? – pdr Mar 6 '14 at 12:25
  • well if you make dedicated tests for Facade, and the rest using it as-if-correct, it is going to be similar to issues described in How to structure tests where one test is another test's setup? - that is, rest of your tests will depend on pass/fail state of Facade test cases – gnat Mar 6 '14 at 12:25
2

In your scenario i probably make diferent test:

  • Unit test of my model/business logic. In this test i mock the abstraction created on Doohickey API. With this test i have confidence in my business logic.

  • One contract test for the abstraction over Doohickey API. With this test i verify that my code work correctly with the API and protect me of possible changes in the APi.

  • Probably i write some integration/system test, in this test i need like you say the Doohickey abstraction to insert data, i use it and don't duplicate code. With this test i have confidence in that all the pieces of my system work together.

If the code for inserting data breaks two test breaks in my system, the contract test and the system test, in fact, when its usual that when some unit or contract test fails one or more systems test fails too. But this give you a lot of information, you know with the unit/contract test the exact piece of code that fails and you know with the systems test the feature that is broken in your system as a result.

2

"If you introduce a bug in the Facade, the test might not show it."

If you don't use the Facade, you will still have to "set up data in the service" (as you described it), so you need to write at least equivalent code. Who says that you don't introduce a bug right there? Or maybe there is a bug already in the facade in the first place and when you duplicate the facade code, what makes you sure you won't copy the bug either?

So I don't see any real reason not to reuse the facade code in your tests - I don't think the chances really get higher that you overlook some errors that way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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