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?
7
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.
“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.