Sign up ×

The shop I work for has recently switched to Agile/Scrum software development. We've started logging User Stories, and defining their scope with Acceptance Criteria. So, we have

  • Features defined by
    • One or more User Stories
  • User Stories defined by
    • One or more Acceptance Criteria
  • Acceptance Criteria validated by
    • One or more Test Cases
    • One or more Unit Tests

We're now starting to look into Test Case Management software for the QA guys. The idea being that it will help manage their growing number of Test Cases. We've been told that with proper TCM software we can associate Test Cases with Requirements (Acceptance Criteria) such that the Test Cases are flagged whenever their associated Requirement changes. The idea being that a QA member would then update the Test Cases as needed.

Now, as a developer, I would like something very similar for my unit tests. Ideally, whenever a Requirement changes, I would like my associated Unit Test to fail. This will let me know that all my unit tests are always up to date.

Does such a system exist? Is there a magical system that will let you manage your Requirements, Test Cases, and allow you to break your unit tests when Requirements change?

Additionally, I would like my build to fail whenever a Feature has been extended (i.e., has had new Requirements added).

share|improve this question
I don't know of anything magical. Wouldn't it depend on how (or how well) you write your unit tests? If your unit tests are detailed enough, any requirement change would "break" them, right? –  Joe Strazzere May 3 '13 at 16:30
Hi Joe, thanks for the reply. What you're saying is true, but only if the application code has already been written to match the new requirements. I'm looking for something that will break my unit tests (or flag them for update) as soon as their associated Requirement has changed. –  MetaFight May 4 '13 at 12:11
Should I maybe transfer this to ? –  MetaFight May 4 '13 at 12:11
Haven't heard of this before. Why fail tests that could be fine? Just because requirements change wouldn't mean that a unit test for a class would need to change. I would think code coverage would work better. If you fail builds when unit tests aren't added wouldn't that accomplish something similar? –  Steve Miskiewicz May 5 '13 at 2:17

2 Answers 2

up vote 1 down vote accepted

It depends on the test framework you are using. The frameworks I know allow you to define your own assertions. With that, you could define a time based assertion like assertSpecifiedBefore(<specification>, <date>), which checks the last modification date of the specification is not newer than the date of test creation (<date>).

share|improve this answer
Sounds like what I'm looking for. Thanks :) Now all I need is a system that I can query when the tests are run which will give me the specification's modification date. I'm pretty sure I can rig something up. –  MetaFight May 6 '13 at 12:00

Take a look at Microsoft Test Manager. Although not dependent on .net, it is fully integrated with Team Foundation System - so if you're not using TFS for work item management / scrum process - it will not work for you.

It does allow you to define standard and custom relationship and you can create your own transitions to invalidate tests if that is what you wish.

share|improve this answer
Do you mean invalidate coded tests (ie, unit tests) or tests withing MTM? –  MetaFight May 4 '13 at 12:32
You would set the test work items in TFS as "invalid" or "not up to date" or smth. –  Bogdan Gavril May 5 '13 at 11:32

Your Answer


