I write an automated acceptance test (AT) and I find that I would like to perform certain actions against the business objects. I create a method on the business objects and my test stays slim while my model builds up more functions.
So, there is potentially code in the production system that is only used in the tests. The debate today is whether that is "unnecessary bulk that solves no business need" or is instead "first-class code."
I am betting that the code you need in the AT is code you probably also needed in the UI and/or APIs to external clients. I am supposing that it is needed in the test because it is likely written into the UIs instead of the model and so the tests' logic is duplication. I also think that even a reasonably poorly-written test is written to support business rules. Therefore, the tests express business logic so methods required by the tests are methods required by business. While some worry that a method on a business object might be picked up and used by a programmer in the production code, I hope that this is true.
Your opinion matters, so feel free to leave a comment.
Tim Ottinger's thoughts on Software Development.
On our team we've been gradually moving towards a model where test code and production code are considered equal.
ReplyDeleteWe have had a past habit of treating the acceptance tests as second class. In our retrospectives we've gradually moved our thinking towards all code has equal status based on trying to solve problems we've had.
I sometimes drop the phrase "Automated testing is customer visible," and people tend to agree.
I have a hard time imagining this team:
1. Adopts a policy of "no test support" in production code.
2. Periodically meets to discuss process problems and adopts solutions.
3. Manages to stick with that policy.
I just can't see how. But I've been wrong before.
For years I was afraid someone will use the "test-code" for production and ruin everything. Once I stopped adding those functions with hacks, but treated them as Real Code (TM), I stopped worrying. These extended the design as I needed, and sometimes I later found good uses for them in production
ReplyDeleteIn my experience the extra code that is needed, often arises from implicit coupling of the UI with the business layer.
ReplyDeleteAnother issue that causes this is violating the law of Demeter (using too many gets instead of telling objects what to do).
So I would say that this very issue is a bad smell in the original code, and would double check it too see if it needs any refactoring.
In my experience the extra code that is needed, often arises from implicit coupling of the UI with the business layer.
ReplyDeleteAnother issue that causes this is violating the law of Demeter (using too many gets instead of telling objects what to do).
So I would say that this very issue is a bad smell in the original code, and would double check it too see if it needs any refactoring.