Thanks to Dion/Cameron, I spotted something way cool:
I'm currently reading Mike Cohn's User Stories Applied and the chapter about user roles included something that was completely new to me so I decided to share it.
Specifically, the part I'm talking about was when Mike referred to possible use of Extreme User Roles to reveal stories for your software that you might've otherwise missed. Basically, the technique works as follows:
- Come up with a set of extreme characters such as "drug dealer", "woman with multiple boyfriends in circulation", "the pope", etc.
- Think about how these characters would want to use your software
Note that Mike is not suggesting that this technique should always be used. He just mentioned that playing around with it for a couple of minutes might be fun and potentially otherwise beneficial. Just don't over-do it.
- Thanks to Carlos, I just learned that the "1.0rcf" version of C-JDBC has been released approximately a month ago. They've also published a new paper on C-JDBC which looks good!
- If you're still missing out on Subversion because you've got all your stuff in CVS, you could try the cvs2svn script for migration (after backing up your repository twice, of course...).
- Darrell recently found out that crunching out some numbers for the management can be a good thing when adding tests and refactoring non-TDD code.
That's about it. Now I'm off to bed.
It just dawned on me that one of the biggest advantages NUnit has over JUnit (considering that I don't have too much experience writing .NET stuff) is that they've named the framework classes perhaps a bit better than the JUnit folks did. I'm talking about org.junit.framework.TestCase, not the usual "we should also use metadata instead of naming conventions" argument that you must've heard 113 times already.
The minor issue I have with TestCase is that, based on my observation, the name tends to lead developers new to unit testing write not-so-good test code. Specifically, while the name "TestCase" implies that the class you're looking at should represent a single test case, the fact that you can write a dozen test methods seems to lead to thinking that it's actually the test methods that are test cases, not the class.
So, what's the actual difference with NUnit regarding this issue I've managed to make up -- in addition to NUnit using attributes to mark up test classes and test methods?
The difference is that for the .NET developer, a test class explicitly represents a test fixture -- something all tests in that class should have in common! This is something that a JUnit user can easily forget, eventually leading to lack of cohesion in the test classes.
Personally, I'm finding the single-assert-per-test-method to be a reasonably good reminder for keeping my fixtures clean. It's just that a majority of JUnit users seem to not agree with this rule of thumb.
Do you see this as a real problem or am I again making it all up? Should the JUnit team apply the "Rename Class" refactoring on TestCase?