Charles Miller shares his Six Rules for Unit Testing:
1. Write the test first
2. Never write a test that succeeds the first time
3. Start with the null case, or something that doesn’t work
4. Don’t be afraid of doing something trivial to make the test work
5. Loose coupling and testability go hand in hand
6. Use mock objects
Blogged: July 25, 2002
link
Kevin Dangoor writes: "Creating software sometimes requires intense concentration and creativity. The pair programming way sometimes yields good solutions by having two people brainstorm on the problem. Other times, thinking about the problem independently works best."
link
Michael Kent writes: "These are the rules I’ve developed over the years that I follow when refactoring code. They’re rules in the sense that I always regret it if I fail to follow them for any reason."
(via John Tobler)
link
Sam Newman writes: "PicoUnit has been developed with a view to reduce the amount of setup within specifications, using Picocontainer to instantiate and pass in the required dependencies. One use is to locate test data from an external source and pass it in."
link
Sam Newman writes: "OO-Matron might potentially be revolutionary, or might just be too complicated for people to use – I’m still undecided. It’s designed to replace existing Mocking APIs, whilst at the same time adding the ability to enforce system-wide invariants to your tests, which in turn can be used to provide system documentation."
link
Darrell Norton writes: "Lately I’ve been adding unit tests around a critical subsystem of the application I am working on. Luckily I had some downtime to add unit tests to cover parts of the subsystem that I did not develop (of course with TDD all of my new code was covered!). Here are some tips I’ve learned in the process."
link
Talip Ozturk writes: "Don’t you love to check out your favorite open source project from CVS and execute ‘ant run_tests’? I don’t but that doesn’t matter. What matter is how you feel when tests end with no error. Fuzzy comforting feeling you get which is misleading most of the time. Of course seeing that unit tests executed with no error doesn’t mean that your favorite OSS project [..] is bug-free."
link
Bret Pettichord writes: "A general rule is that a test has value proportionate to its ability to find bugs. I think this is mostly true. Sometimes this ability is referred to as the power of a test. Powerful tests are more likely to uncover bugs than weak tests."
link
Andrew Koenig writes: "An unprovable error is one that no amount of testing can ever be assured of revealing. With computers becoming more networked and security becoming more important, should we be thinking about how our programming tools can avoid unprovable errors?"
link
James Bach writes: "[There's] a syndrome in test automation: automation is too clean. Now, unit tests can be very clean, and there’s no sin in that. Simple tests that do a few things exactly the same way every time can have value. They can serve the purposes of change detection during refactoring. No, I’m talking about system-level, industrial strength please-find-bugs-fast test automation. It’s too clean. It’s been oversimplified, filed down, normalized. In short, the microbehaviors have been removed."
link
Benjamin Mitchell blogs his notes on James Newkirk’s TechEd EMEA discussion on unit testing/test-first, held June 30, 2004. "An excellent give and take on a number of issues that are really pertinent to unit testing."
link
Julian Bucknall addresses the use of the Free command to deallocate memory, and brushes on its relevancy to test-first development: "If you follow TDD guidelines, you won’t use try..finally, Free. Why? Because, in the majority of situations, you’ll be writing code that’s not necessary and this runs against the mantra of TDD: write only the simplest code you need to pass the current test."
link
Steve Freeman writes: "At ADC2004 I was chatting with Ward Cunningham about the origins of Test Driven Development. He said that, for him, it came from working with a group that was working in parallel on the same code base. The domain was mathematical and so pretty straightforward to test, so he pushed the testing forward to make sure that they weren’t stepping on each other."
link
Steve Eichert writes: "I’ve recently written a series of posts on the process of automating the unit testing of CRUD operations on business objects. [..] In future posts I’ll dive into some of the details which I didn’t go into such as how to set the allowable values for a property, how to ignore a property when comparing objects, how to set a property value as unique, as well as how to manage relationships among objects. Look for a zip file containing a running example in the next couple of days."
Chris Nokleberg writes: "In Rickard’s recent entry he discusses a technique whereby abstract classes can implement an arbitrary set of interfaces, the missing implementations of which are ‘filled in’ by his AOP framework. I’ve done something very similar with CGLIB for my own Mock Object needs."
link
Martin Fowler writes: "I was working on some example code for one of my writing projects recently when I ran into a failing test. ‘Ouch’, I thought, ‘those tests were passing last week – what happened?’ Rather than trying to find the bug in the code in front of me, I used what I think I’d like to call diff debugging."
link
Steven M. Cohn writes: "AndrewSeven was kind enough to direct me to a blog by James Newkirk briefly introducing the PrivateObject class available at part of the VS Team System framework. I was intrigued enough to start investigating and ended up implementing what I think is a close interpretation of this class, shown below."
link
James Newkirk writes: "I know there is nothing that I can say that will be viewed objectively, because I am a Microsoft employee and I have been tangentially involved with the VS Team System development team (I am the development lead for the patterns & practices). That said, I would like to dip my toe in the fire of ‘Why unit testing in Visual Studio Team System’ which I translate into ‘Why unit testing in Visual Studio Team System and not just plain Visual Studio’."
link
Tim Bray writes: "Over the last twenty years I’ve seen the rise of Structured Programming and Object-Oriented Programming and Message Passing and the Relational Model and those are all good things, but TDD is the single biggest advance in my lifetime. It might (finally) turn software from an amateur’s kitchen to an engineering discipline. Herewith some more anecdotal evidence, and practical advice for Software Development managers."
link
Jason Anderson writes: "We see a lot of value with the integration of Unit Testing and Code Coverage. The shared scenario of being able to write and execute your Unit Tests integrated with the ability to examine Code Coverage data concerning the effectiveness of those Unit Tests is remarkable. Additionally, we see a huge value in the integration of Unit Testing with Load Testing. Adding Unit Tests with other tests types (such as Web Tests) to a Load scenario and turning the dials to make a custom load environment gives developers and testers an extreme amount of testing power."
(via James Newkirk’s blog)
link
James Newkirk writes: "One of the often requested features of NUnit was the ability to test private member variables and private methods. I resisted because I always felt that if you limited yourself to the public interface that enabled you to freely change the implementation without having to change the tests. This I believe is a good thing because if the tests require a lot of maintenance you might be tempted to not do it. However, the flip side of the equation is you may end up exposing a method or worse yet a member variable only for testability. The downside of this is that once it is present in the interface it could be used for something else."
link
Bill Dudney writes: "The other day I was taking with my friend Kent who works for Agitar Software, a vendor of a really cool unit test automation tool called Agitator, and he was saying that they found an interesting bug for one of their clients using the tool."
Highlights the need to test all code, including freeware bits obtained from reliable sources.
link
William C. Wake writes: "Refactoring [..] has a psychological side: a better design, but also a different design. A different design may induce people to act differently (indeed, that’s why we do it!). In particular, a different design may give people different expectations about code."
link
Martin Fowler writes: "One of the most common questions I see about agile projects is how they deal with handover to another team. If you have a development team that leaves and hands over support to a support team, how do they cope when agile projects tend to produce much less documentation than plan-driven processes?"
link
Len Holgate writes: "I’ve been finding that since I’ve been using TDD and JITT I end up with many more classes than I used to have and each of them does less. Cohesion is up, coupling is down, functionality is split in a more orthogonal manner and the objects appear to be easier to reuse."
link