in reply to Organising Large Test Suites

Personally, I would have a way of uniquely identifying each test in your test suite. Then, you can specify in the RT report which test it is. The key is the unique indentifier for each test in the suite. Now, you don't have any difference between "bug tests" and "new dev tests". Frankly, in TDD, you fix bugs the way you write new code - with a test first. A bug report is a requirement. Instead of coming from the business analyst, it comes from the user. Either way, it's still a requirement.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Replies are listed 'Best First'.
Re^2: Organising Large Test Suites
by eyepopslikeamosquito (Archbishop) on Jun 07, 2004 at 04:25 UTC
    Personally, I would have a way of uniquely identifying each test in your test suite.
    I think it's better to assign the unique id to the bug/test-case because they tend to be more stable than the test suite (especially when you start refactoring).
[reply]
      If you give each test a unique identifer, you can also track which tests handle which requirements. I know this would be useful for other reasons.

      The ID should be something that is on the test-level without reference to which file or subsystem it deals with. Maybe, an order of creation? Then, the test suite is actually just a list of the individual test IDs that should be run?

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]

In Section Meditations