A place for brain dumps.
I’m always having to explain why line coverage is misleading. This is probably the best, most obvious example of why.
See, 100% coverage!
So let’s reformat some code, you know, just ‘cuz we prefer do … end rather than curly braces.
Oops.
Know what your tests do, people, don’t just look for the nifty green bar from rcov.
I really thought I would hate using autotest. Then one day I kinda got tired of using command-r to run the test file I was editing. Well, truthfully it was having to switch back to the test file when I was editing the actual code itself.
Just now I realized how freakin’ smart autotest manages to make itself. I changed a fixture yml file and went over to the autotest window to kick it, assuming it wouldn’t run all the tests that use that fixture. Nope. It was happily running all the ones that depend on it. Freakin’ magic.
Now that I get annoyed when autotest isn’t running, I know I’m officially a convert.
For simple things like this:
ruby script/generate scaffold user admin
It means exactly what it sounds like when you read it aloud, “Generate scaffold for user admin.” 
“A test is not a unit test if:
- It talks to the database
- It communicates across the network
- It touches the file system
- It can’t run at the same time as any of your other unit tests
- You have to do special things to your environment (such as editing config files) to run it.”
This really rings true for what I’ve seen lately. Partly it’s a matter of syncing up definitions. I’ve worked at jobs where “unit testing” meant “go test the webapp on all the different browsers.” I call method-level (or object-level) tests unit tests. Lately a lot of people have been calling tests that require a full database, populated with lots of data in a very specific setup unit tests. It just makes me want to scream, “That’s not a unit test!”
That doesn’t mean you shouldn’t write tests that require a network, or a database, or anything in that list, for that matter… I just call those integration tests. They’re no less good, they’re just for a different purpose. In “nirvana land” those are used to ensure that the QA environment is good, that all your code compiled together is good, there are no configuration issues or there are no unintended side-effects, that sort of stuff.
The tricky part is explaining that to people. I get it, I mean, if you haven’t seen “nirvana land” it’s hard to grok it. It’s where you don’t notice the code doesn’t have any comments. It’s where you don’t have to think so hard about every change because you trust your tests to catch it. I miss “nirvana land”.
I have a plan, though.
Stupid underpants gnomes and their half-baked plans. I need a step 2.
As an odd side-note, you don’t need automated unit tests to be there. My first experience with perfectly readable code was the gtk+ code for one of the early releases of the Gimp post-motif. It’s just that automated unit tests happen to make it a lot easier, therefore it takes less smarts (i.e., drunk programming), less time and just plain less effort.
I’ve been using Subversion for real development for a few months now. I’m mostly surprised this didn’t come up sooner.
It seems subversion doesn’t handle the case where two different people add the same file at the same time. The second person to check in won’t be able to. It fails for directories, too, and the error message can be confusing.
When you do an svn up you’ll see a message like this:
bash-2.05b$ svn up svn: Failed to add directory 'baz': object of the same name already exists
But on a commit you’ll see this:
bash-2.05b$ svn commit -m "testing subversion, still" Adding baz svn: Commit failed (details follow): svn: MKCOL of '/viper/!svn/wrk/6b9bcd38-b2fe-0310-95ff-9d1a44098866/sandboxes/ohammersmith/trunk/baz': 405 Method Not Allowed (http://svn.motricity.com)
If it’s a file, the error message is much more useful.
So the moral of the story is, make sure you do an svn up before you attempt a commit. You should do it, anyway, and the error messages are way more helpful.
Someone asked me the other day what books would be the best place to start grokking test driven development. I know he has the memory of a senile gnat on crack and happens to read this so I’m repeating myself. Plus I thought it might be helpful for others, too.
Disclaimer: I’m in a Java shop so this list might be a little Java-centric.
I’ve listed the books in the order that I would read them. The first two are short, and could be read in a weekend each.
Test Driven Development: By Example by Kent Beck.
This one is one of the first books on the subject I had read. I think it’s an extremely helpful book if you don’t really grok the concept of test driven (or test first) development. You have to work through the examples, but they’re reasonably short so it’s definitely worth the time.
The best example, is xUnit, builds up the equivalent of JUnit in Python from the ground-up. The theory here is, if you can build a unit test framework test-first, then you can build anything test-first. This section alone is worth the book. (For the Java-heads, it’s easy enough follow along in Java, I’ve done it.)
This one also happens to exist on the Safari Bookshelf.
Pragmatic Unit Testing in Java with JUnit by Andy Hunt and Dave Thomas.
This is a good intro book, and probably even useful for handing to managers who don’t “get it”. It is a little light on examples, but that’s what the previous book is for. It’s essentially a good overview, and it happens to round out the trilogy of the other books in the Pragmatic Starter Kit and I felt the need to have the whole set.
JUnit Recipes : Practical Methods for Programmer Testing by J.B. Rainsberger.
I wouldn’t suggest this book as a place to start. It is set up more as a reference, than a book to read cover to cover. But, if you’ve found yourself asking “How do I test my EJBs?” or “How do I test a Value Object?” this is the place to go.
This book is more useful as a reference, but it is still useful to read through sections of the book so you know what tools are available.
There are definitely other good books on the subject, but I think these books get you to actually programming this way fastest. That’s where the actual understanding comes from, once you see it in practice and start thinking in the test-first mind-set.
A while back Joel, over at Joel on Software posted a new article on coding conventions Making Wrong Code Look Wrong.
I think his point was legitimate, but maybe clouded by the fervor with which people hate Hungarian notation. The central point that coding conventions should be used to make wrong code look wrong. It may be that Hungarian is a reasonable solution for a procedural environment.
The best Java analogue I can think of is RequestDispatcher.forward(). You *have* to return after that call, or you’ve just created a bug. It may not crop up, but if you don’t return and then some other piece of code tried to modify the response *boom* it blows up.
So how do you make this look wrong:
RequestDispatcher dispatcher = ServletContext.getRequestDispatcher("path");
dispatcher.forward(request, response);
and make this look right:
RequestDispatcher dispatcher = ServletContext.getRequestDispatcher("path");
dispatcher.forward(request, response);
return;
That’s the kind of thing I started thinking about when I read that article.
You can’t extract a method, because you’ll just create another method that requires a return after it. So I think the answer is to make a dictate against such methods. Since we can’t change the J2EE spec, we should leave RequestDispatcher.forward() calls bare. At least, then you can recognize one of the few methods that are missing the required return.
The bit I haven’t figured out, yet is what would the J2EE spec look like if we could change it. That’s a topic for another time.