These are the highlights from 2nd to 8th February.
- Scott Bellware: Teaching, symbology and intellectual materialism
- Coding Horror: Mixing oil and water
- Object Mentor: Speed kills
- Los Techies: Why "Should attach view to presenter" in an invalid unit test
- NOOP.NL: The decline and fall of agilists
- Elegant Code: Software development "Lessons learned"
- Signal vs Noise: Why you shouldn't copy us or anyone else
- The Runtime: Professional values
- Coding Horror: Don't reinvent the wheel, unless you plan on learning more about wheels
I make no secret of the fact that I'm a fan of using unit tests as part my development process. I am the example of a test infected developer. The problem I have is conveying the benefits to the people I work with in order to get them aboard the testing train.
The main problem is that writing tests is hard. Sometimes very hard. When you start you have to get your head around a unit testing framework, mocking and perhaps even interface based development. Then you have the hurdle of taking 5 minutes to write code that previously took you 30 seconds. You feel like you are robbing your employer of productivity. I think this feeling of guilt could be one of the main reasons people don't stick with tests aiding their development.
Notice I have not at any point mentioned writing your tests first. Though I feel this is the most effective way of using tests in your development; it does require a large change in the way you think. I'm happy to leave out yet another barrier to the uptake of test aided development.
So what's so great about having tests as part of your development?
One of the simplest is that you can have more confidence changing the code you have tested. If you know that most the logic in a section of code is covered by tests you can be more confident changing code in and around it as tests should fail if you break something.
Another benefit is that you get a feel for when your code is doing too much. This will come from your tests being hard to set up. A method might only be 6 lines long but if you have to set up 5 dependencies to test it you know something's wrong. You probably wouldn't notice this sort of thing without having to write the test. Similarly if you have to set up 10 tests to cover all the paths through a method too much is going on in that method and it needs refactoring.
Following the forces of these extra sources of pain will aid you to produce code that is well factored and easier to debug. How is it easier to debug you may be thinking. Well if your code is easy to test each method will be doing very little making a stack trace even more useful than normal. Also reproducing a bug through a test should be easy as your code will already be easily testable. Every developer knows that once you can reproduce a bug you're 95% of the way to fixing it. The test will also remain as a safeguard against the bug reoccurring.
Using unit tests in your development is not only about testing itself. It is about having another source of information on the quality of your code. The benefits of the suite of tests remaining after are just a great side effect.
For a long time I've been trying to get to grips with a build language. Until recently all my attempts had been with NAnt and I found it very hard going and rather inflexible. I mean who thinks programming in XML makes sense?
I've recently been learning Ruby in an effort to put into action the advice from the pragmatic programmer and start scripting repetitive tasks as well as giving myself a wider knowledge of dynamic programming. From my exploits in Ruby I bumped into Rake again. I'd read about it when looking into build languages but I had gone with NAnt as that's what all the cool kids were using.
Rake, in case you weren't aware, is an internal DSL written in ruby for automating build processes. This is where it differs greatly from NAnt. NAnt is an external DSL for the same task. What an internal DSL allows you to do is utilise the underlying language when you need to. This also means that with Rake you are defining your build process through a Ruby script rather than XML. This makes a hell of a lot more sense to me.
Because it makes more sense to me I've been able to get to grips with it a lot quicker. It took me an hour to get to grips with Rake with only a basic knowledge of Ruby. I've spent days trying to use NAnt and never really got anywhere with it. After a day with Rake I've got my full build generating custom documentation from the XML generated by my tests. I dread to think how long that would have taken me with NAnt.
That's the real beauty of Rake. It is simple to leverage your existing programming knowledge to extend your build to do anything you want as you have the power of the Ruby language backing you up.
So if you're having a hard time with NAnt or are looking at enhancing your build process past Visual Studio I thoroughly recommend having a look at Rake. You might even learn an extremely useful scripting language into the bargain.
References I found useful:
These are the highlights from 27th January to 1st February.
- Elegant Code: Agile in the trenches
- Leading Answers: Batch size and velocity fluctuations
- Mike Taulty: Why is deleting code so satisfying?
- Coding Horror: The ultimate dogfooding story
- Mike Taulty: Anonymous methods, lambdas, confusion
- Signal vs Noise: How we reduced chargebacks by 30%
- Scott Hanselman: Read the expletive log file
- Code Better: Overriding global T4 templates in ASP.NET MVC
- Signal vs Noise: Great self promotion
- Elegant Code: Refactoring the refactored switch statement
- You've been Haacked: T4 templates in ASP.NET MVC