Arguing Through Unit Tests

We have noticed that UnitTesting leads to an interesting cultural change, whereby you start ArguingThroughUnitTests. I witnessed this with some bemusement...

I first noticed this when my partner and I had a disagreed on how to do an EngineeringTask. What was the simplest thing?

At first, we made the mistake of just looking at the code, and the argument became more and more heated (We were still new at this, and you do drop into your old ways). Then one of us got wise, and said to the other, "Well, how would you test that, then?" He grabbed the keyboard and keyed in the rough sketch of a test - I disagreed, and typed a different test underneath. Through our tests, we explored ramifications - and the rules of the game that emerged seemed to be that in order to talk about any code, you had to have mentioned it in your test.

In retrospect, we argued too long before rolling up our sleeves and getting on with it - however what emerged was that we diffused the heat of an argument and converted it into TestEnergy. We remained friends and eventually we saw that there was an overlap in our tests - interestingly this proved to be the SimplestThing. (In fact the solution was 2 lines of code, whereas our initial ideas introduced several new classes).

I think this experience has improved my understanding of DoTheSimplestThingThatCouldPossiblyWork, I can also see that when faced with a contentious issue, ArguingThroughUnitTests is a useful mechanism. When arguing, keep an eye open for any overlap, as this might be a clue to the SimplestThing.

After this experience, I have noticed this phenomena with other pairings I have had. Has anyone else encountered this? -- TimMackinnon

I do this when programming alone. I'll have a general idea of where I want to go. Instead of thinking hard about it in the abstract, I'll code up a test case or two. I also do this in design reviews- "I don't quite understand what you're saying. What's an example test case?" --KentBeck

Not sure I understand your comment Kent - arguing with yourself sounds scary.... I will talk with my partner tomorrow and see if we can reconstruct the scenario. What I remember was that I had a perfectly valid solution in mind - it seemed quite simple to me, and I could write down a reasonable UnitTest. However my partner also had a valid different solution in mind which he could also argue convincingly with a UnitTest. Arguing at the UnitTest level seemed to be an important way of defusing an argument - and a better way of expressing your idea. It's more concise, you can point to it, criticize it (rather than a person). Its also seems more malleable in the face of an argument - "You don't like the use of that result? Well what if just remove this line and ask the other guy for the total - the effect should still be the same... (other guy) - No, No, you don't even have to ask for that total, in my test here, we can just assert that there is one less value available". --tm

Assertions can be useful in a similar way: for example, we thought there was a threading problem, and so inserted

Assert.invariant(SwingUtilities.isEventThread());

to check it. -- MartinPool

moved from UnitTests

We have noticed that UnitTesting leads to an interesting cultural change, whereby you begin to to start ArguingThroughUnitTests. I witnessed this with some bemusement, and decided to write it up -- TimMackinnon

I noticed that at my last place of employment. In particular, I noticed that my blood pressure seemed to be a lot lower, my general view on life more optimistic, and more of my time at work spent on coding, rather than arguing with people who were sure I had broken something. -- KaelLizak

I think TestFirstDesign will eliminate the problem of arguing through unit tests. Don't write a full blown test of everything the code is intended to do. Agree on one simple data point the code must meet. Write that test and only that one test (you may need to write a null function in the code to allow the test to compile). Run the test, prove that it fails. Write the minimal code to cause the test to pass. Agree on one additional data point and repeat the process. Once you have reached the end of agreed upon data points, check everything in and you are done for the day. For any items you cannot agree on, bubble the question up to a customer representative and let him make the call.