Looking for some practical advice here and any experiences people have had in a similar situation.
We use a BDD/TDD sytle methodology for building our software (quite a large/complex application) The end result is.. behavioral specifications (Given/When/Then style) derived from business requirements, unit tests that reflect these and code that reflects the requirements of tests.
However, recently our test department has started running integration tests, and understandably they want to use our (already passing) business logic code to set up and tear down test state (rather than having to deal directly with a database) as they are mainly concerned with testing via the UI of the application and do not want to spend all day wrangling databases.
The problem is, some of the Entity Repositories do not have delete methods as there has been no business requirement expressed for these yet. Many have Archive/Reinstate/backup etc. (and may have delete pending on the backlog).
So now we have a test dept. requirement for deletion (but one which conflicts with business user stories)
So.... My question is... if I were to add methods specifically for the test department... what't the best way of handling these. I understand that this is generally considered bad practice in "TDD Utopia" but realistically, how have you dealt with this kind of conflict?
The first thoughts I have had are either use naming...
void TestOnly_Delete(Guid id){}
...attributes...
[TestOnly]
void Delete(Guid id){}
... or compiler directives...
#if TESTBUILD
void Delete(Guid id){}
#endif
So at a minimum, developers can know not to call TestOnly methods and at a maximum, test methods are not deployed in production builds.
... or just cheat and add a user story to manage it that way ;-)
Any experience or advice gratefully appreciated?
Thanks in advance.
TDD usually means using unit tests to drive the creation of the production code being written, but it can be applied at any level. For the purposes of this post, though, we are going to stick with the most common application: unit testing.
Testing Techniques in Agile Software Development TDD, BDD and AMDD are the techniques in software testing that can be applied to any methodology. TDD is Test-Driven Development. The unit tests are written first, then a code is written to make the tests pass.
Unit Tests Should Only Test Public Methods The short answer is that you shouldn't test private methods directly, but only their effects on the public methods that call them. Unit tests are clients of the object under test, much like the other classes in the code that are dependent on the object.
Your first concern should be does adding this functionality enhance or deteriorate the current API? A typical scenario in TDD is that a class member is (initially) only required for testability reason, yet it conforms to all normal API design guidelines, so it does no harm (and often subsequently turn out to be a valuable addition in production code as well).
When this is true, then by all means just add it if you can do so easily.
Sometimes, however, the reverse is the case. In this case, you must resist the urge to add the member. However, often you can follow the Open/Closed Principle and open up your API so that others would be able to add the desired functionality. Testability is really just another word for the Open/Closed Principle.
In your case, the simplest solution might simply be to ensure that the classes in question are unsealed and then ask the Test Department to derive from those classes and implement the functionality themselves. If they don't have this capability, then you can do it for them, while still keeping the sub-classes test-only.
In my code, I create a subclass: for example, if I have a DataLayer
class which has all the public methods to access the data layer, then I might subclass it with a Test_DataLayer
subclass, which inherits methods from DataLayer
and which furthermore implements any additional methods that you might want like Delete
, and whose implementation can access internal or protected methods of the base class.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With