I have attended Steve’s presentation of the code tester and have a fair idea of the direction Quest is going with it, and I like what I see so far. Our group has developed a large body of unit tests using UTPLSql and this looks like a great extension of a good idea.
We have written a code generator that generates UTPlsql test packages and have added functionality that we find very useful. I would love to describe these features in some detail in hopes they could be included in your code tester, and then I can look toward desupporting our in house generator and us yours.
I will post my suggestions in another ‘enhancement request’ thread (unless you can suggest a better way to share these ideas), but would like to reply here to the current topic, the dependency of test cases.
I would add my vote to the request to allow prerequisites to be linked between unit tests. I help a large team of developers with their unit testing, and I ‘own’ the core unit tests. I understand the idea that tests should be independent, but our applications are so complex that it’s a huge waste of time making every developer write 90 setup cases so they can test their small dependent procedure or function when there already is a complete, tested setup available in another unit test.
I already know that if I break my core applications, all the dependent applications are broken. That’s daily life with a complex business application. It’s the same thing with the unit tests. I not only don’t care that there is a dependency between unit tests, I want that. If I break my core unit tests, and everyone else’s breaks, that’s a good thing. I makes me make sure my core tests are perfect. It also means that I don’t have some developer who doesn’t know the core app writing an inappropriate or incomplete setup that makes his test cases succeed, that would otherwise fail give then correct setup. We have already convinced management of the necessity of allocating time for every single piece of code to have a unit test, but if they knew that 10 developers where spending 50% of their time duplicating setup cases manually, they would start to ask tough questions, and rightly so.