I was in the middle of a TDD coaching session a couple of days ago when it hit me - people need a tool that will help them write one assert at a time!
So I started looking for one, and after about 2 exhausting minutes of trying to Google it, I gave up and wrote one myself.
Give it a try at http://www.rauchy.net/oapt.
I just found out that you can create compound constraints in NUnit (starting in v2.4). This means that you can logically group constraints.
For example, I am currently testing a custom IList<T> implementation, and in a specific test case, I want to make sure a specific entry exists instead of another. Before compound constraints, I would have written these 2 asserts:
Assert.That(this.subject, Has.Member(”rauchy”));
Assert.That(this.subject, Has.No.Member(”Omer”));
My problem with this code is that these two asserts represent a single fact - I want to make sure that rauchy makes it to the list, and not Omer. One might interpert them as two independent facts. With compound constraints, I can just write:
Assert.That(this.subject, Has.Member(”rauchy”) & Has.No.Member(”Omer”));
This way, you cannot think of this as two independent facts. Also, this helps follow the one-assert-per-test rule.
I found myself in an interesting coaching spot - I am going to teach Alt.NET to a programming infant. I’m going to create the first Alt.NET baby.
Real life sometime brings you to strange situations. I lead a development team which is building a web application and we recruited a new member a couple of weeks ago. I’ll refer to him as “the baby”, since he never wrote a single line of code.
Why is he on board, you ask? Well, he’s a fresh computer science student and knows his way around the presentation side of websites (good knowledge of HTML, CSS, Javascript and good ol’ web black magic) so this seemed like a good trade-off for both sides - the baby will join the team and help us out with his mighty presentation powers and in exchange will be part of a real project for the first time and will get on-job-training.
This is an interesting spot. Computer science has brought his knowledge to a certain level so far (basic C) and I need to catch him up with:
Oh, and this needs to be done as we go on with the project.
Can you think of anything I forgot to mention?
Does the order make sense or would you suggest a different one?
Eeek.
Having been involved in test-driven projects over the past 2 years, I found myself explaining the advantages and disadvantages that test-driven introduces to software projects to many people whom I taught, trained or coached.
I always stuck to the usual points, for instance, “design by usage”, “safety-net for your code”, “faster drilling to the heart of the problem”, “provides documentation for your code” etc. These are all great advantages for the project, and everyone in the project (including management) eventually enjoys them.
Lately I have been asking myself – why is TDD good for me? How do I profit from it? What’s in it for me? And most important: Why do I deliberately get myself into TDD adventures and even dare to say that I enjoy it?
Well, the answer is simple: Test Driven Development allows me to be an idiot, and keep getting paid for it.
When writing code, I face two tightly-related problems: Functional requirements (making sure my code does what it’s supposed to do) and design requirements (making sure the code is simple, efficient, coherent, extensible etc.).
Solving both these problems is a big headache, and I often find programmers failing to provide a solution for both of them. I often find poorly designed code which answers its requirements or well-designed code which does not.
TDD allows me to split this headache into two manageable problems.
Following the Red-Green-Refactor mantra carefully, I start with writing horrible, horrible code which answers the requirements. I continue making it all the way to the green stage and continue iterating until I have a hefty, sloppy method which answers all its requirements.
From that moment on, I do not need to worry about the functional requirements any more as my code is already obliged to solve them by unit tests, and any slight shift from that obligation will immediately come to my attention.
This is the part the real fun sets in. I have the freedom to design (actually, redesign) without worrying about breaking functionality. Like a lucid dream, you can do whatever you want, without the risk of getting hurt.
This way I can concentrate on each phase separately:
When answering requirements, I just have to make sure the code does what it is supposed to do, even at the price of code duplication, inefficiency and plain ol’ dumb code.
When refactoring, I have a well-set environment that allows me to apply design techniques without worrying about functionality.
This raises a question – can the role of the modern developer be split to two as well? A less-experienced developer will handle functionality and a more experienced developer will refactor?
If you liked this article, 
One of the ten commandments in Unit Testing states “Thou shalt not access files during unit tests” (check it out here).
I can’t agree to that entirely, as I have been involved in a system whose main functionality dealt with files. In order to make that system unit tested, we had to permit file access for our unit tests. But these days I am working on a project which heavily relies on text analysis, and for this I find CommentReader extremely comfortable.
In a sentence, CommentReader allows you to use text from your test’s comment block inside your unit test. For example:
/// <input>
/// This is my input
/// </input>
[ Test ]
public void YourTestName()
{
string input = CommentReader.GetElement( “input” );
// input == “This is my input”
...
}
This way you can make sure your test resources goes along with your test (if you make sure to enable Xml comments, of course) and no other test.
I think its a very elegant solution, as it immediately states what the test’s intentions are. You don’t have to open Xml documents for that any more.
http://www.bestbrains.dk/dansk.aspx/Artikler/Using_Files_In_Unit_Tests
I was trying to figure out which unit testing framework to adopt on a project I’m involved with. My hunch was definitely NUnit & MbUnit ( where appropriate ), but a couple of dudes in the project pulled an impressive comparison table that almost had me convinced on choosing Visual Studio Team Test. Then I stumbled upon the following post by Roy Osherove ( bow down ) which made me realize that Visual Studio Team Test is probably not the way to go any time soon. Make sure you read the discussion following the post.
The main issues that pissed me off are:
Unless you are applying design techniques to your unit tests, they can become quite messy. In such cases, being familiar with these anti-patterns can help you stay away from trouble.
An excellent beginner’s article.
I recommend this to everyone I teach TDD.
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| « May | ||||||
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
