This is a historic post, which I felt needed updating to reflect my current position.
Whilst I still feel that NCrunch is expensive, I feel that price now needs to be put into context. In the three years since writing this, I’m been waiting for an alternative to appear, at a more reasonable cost. The obvious candidate would be JetBrain’s dotCover. That latter product has improved greatly over the last couple of years, and is much cheaper (ReSharper Ultimate, which includes ReSharper, dotCover and other tools costs $957 over three years, versus $577 for just NCrunch over the same period). However, dotCover still doesn’t run your unit tests in the background as you type. It only runs on a build.
Because of this, and despite its high price, I now both have a licence of NCrunch for myself and have budgeted for buying licences for the rest of my team during 2016. It’s expensive, but I’ve reluctantly concluded it’s a justified expense.
Around a year ago, I restarted developing using C#. I’d used it a few years previously, but hadn’t really looked at it for more than four years. One of the big changes I noticed was with free libraries and tools. When of the things that used to frustrate me with the .NET world was that it was affected by the Windows “charge for everything” mentality. In recent years though, that has changed and free, community-driven, tools and libraries are now plentiful.
Another big change has been the change in attitudes to testing. Four years ago, many developers didn’t know about test driven development (TDD), much less use it. This of course applied across the industry, not just with .NET. I discovered though that – thanks to Remco Mulder – C# had probably the best unit testing tool ever: NCrunch, which was free whilst in beta. Continue reading “NCrunch: or how to ruin a product with greedy pricing”
NUnit’s custom constraints support is a powerful feature for improving the quality and clarity of tests involving objects with complex state, yet – by themselves – the syntax is messy and difficult to read. However, a simple trick of using static methods can greatly enhance the readability of these constraints. Continue reading “Improving NUnit custom constraints with syntax helpers”
Writing good quality unit tests for your code can be hard. Neither multiple asserts in one test, nor multiple single-assert tests are ideal solutions. There are alternatives though, which this article explores. It culminates in a description of a powerful way of writing tests using NUnit.
Continue reading “Using custom constraints to improve NUnit test quality, part 2 of 2”
Writing unit tests for your code is a laudable thing to do. Most developers who have tried using a test-orientated approach to development will agree that it is a superior approach to development, compared with not writing them. However, writing good tests can be hard. This two-part article explores the arguments for multiple asserts verses multiple single-assert tests and – having explained why neither is ideal – examines a powerful alternative that solves the problems with both approaches.
Continue reading “Using custom constraints to improve NUnit test quality, part 1 of 2”
“Test Driven Development (TDD) is great. TDD is awesome. TDD will give you 100% code coverage. TDD will give you clean code. TDD is your coding saviour. Evil sinners test after they code and their code is bad. ‘Test first’ is the only one true way. You are a professional developer only if you use TDD. All bow down and worship at the alter of TDD. Oh by the way, TDD isn’t a religion. Honest.”
The above is my précis of chapter 5 of The Clean Coder by Robert C Martin. Continue reading “Welcome to the Church of TDD”
Recently I wrote an article that challenged the software accepted practice of hiding methods away using the private keyword
. Instead I suggested that using protected is actually better practice. In this article, I present a real-world example of this philosophy whereby switching from private to protected makes it far easier to unit test one’s code Continue reading “Real world use-case of “use protected, not private””
The first talk of the day, by Stefan Norberg
, was frustrating for me as it really brought home how much we constantly re-invent the wheel with software. Continue reading “QCon Day 3: Without an acronym, you are nothing and other ramblings”
Phil Haack recently wrote
about a paper published in the Proceedings of the IEEE Transactions on Software Engineering entitled “On the Effectiveness of Test-first Approach to Programming”
. The paper reported the results of an experiment into the relative merits of the test-then-code approach over the code-then-test approach and proudly concluded:
We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive. We also observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed.
As Phil’s post explains, the results are not the end of the discussion, but they appear to provide the much requested evidence that TDD is a cost-effective and worthwhile tool that ought to be used when developing software.
However the conclusion above and the paper’s results don’t quite tie up. Jacob Proffitt writes an excellent critique of the paper and its conclusions. He points out that the results show better quality and productivity when unit tests are written after the code. Continue reading “TDD is Proven to Improve Quality and Productivity. Allegedly.”
Sometime ago I posted an article on Test Driven Development
(TDD) and promised that some useful links for the following day. I then ran into a problem. Two of the links I wanted to use were on Robert Martin’s butunclebob.com
, which no longer seems to be working. However I have now found his “Three rules of TDD” on another site
. I really like them. The reason is that they sound a really stupid set of rules if one hasn’t done TDD and yet, once one has used TDD for a while, they are spot on. They are therefore a useful benchmark as to whether you have “got it” with regard to TDD. If they sound daft to you, then you either haven’t done TDD yet, or you are doing it wrongly.
The butunclebob.com site also carried a powerpoint of a famous TDD example, the Bowling Game Kata. As the site is down, I’m serving the file from my site. I’ve contacted the copyright owners, www.objectmentor.com, to check if I can do this, so it might disappear in the future if I’m not legally allowed to.
Wikipedia carries a good article on TDD that is well worth reading.
Finally for now, the best source of all things TDD is TestDriven.com. They have a huge range of good quality material on TDD all gathered in one handy place.
I plan on making this post a constantly evolving one to which I’ll add more links as and when I find them. You may well wish to bookmark this page therefore.
Last Friday, myself and a colleague, Laurence, undertook what is possibly one of the most nerve-racking things a developer can do, in what is otherwise a very safe line of work: we wrote code in front of people. Now if you have never done this, you’re allowed to wonder what the big deal is; if you have, you’ll know what I mean. There were around 30 people, effectively looking over my shoulder whilst I wrote the front end to a super duper game: noughts and crosses (or tic tac toe if you prefer). It was extremely nerve racking; but it was great fun too.
Why would I want to write a game of noughts and crosses? Well we were giving a presentation on Test Driven Development (TDD) to Eurotherm’s R&D department. To do such a talk, one really needs to write some tests, and if one writes tests, one really needs to write code to pass those tests. Thus why I was sitting there, with people watching me write code. The presentation went very well, despite it being the first time either myself or Laurence had attempted such an ambitious task. Now part of the reason it went so well is because I have learned that essential ingredient to any presentation: rehearsal. I practised writing the code about ten times before the day. But I also think there was another ingredient to the success: TDD itself.
Continue reading “Test Driven Development is Great!”