Question

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.

Answer 1

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.