Off to Berlin

I’m looking forward to going to to Berlin next week for RailsConf Europe. Last year’s conference was interesting and great fun.

This year I’ll be speaking with Alan Francis on organising a regional conference.

Thursday, August 28, 2008 | Permalink | 0 Comments

Clarke Ching’s Bastard CEO

Being such a nice chap, Clarke’s having writing the Bastard CEO in his soon-to-be-published business novel. Ironically it is incredibly easy for someone in a position of power to become an arse-hole: all they have to do is ignore their elevated rank.

In Gore Vidal’s historical novel Julian, the newly created emperor is taking a bath while discussing politics with his uncle, a distinguished senator, when his friend Oribasius arrives:

I submerged for a moment, eyes tight shut, soaking my head. When I came to the surface, Oribasius was sitting on the bench beside my uncle. “That is no way to approach the sacred presence.” And I splashed Oribasius very satisfactorily. He laughed. My uncle Julian laughed too, for I had soaked him as well. Then I was alarmed. In just this way are monsters born. First the tyrant plays harmless games: splashes senators in the bath, serves wooden food to dinner guests, plays practical jokes; and no matter what he says or does, everyone flatters him, finds witty his most inane remarks. Then the small jokes begin to pall….

Before he became emperor, Julian would have received some censure for splashing a senator: he has now lost that feedback; as emperor he now must either have the discipline and self-awareness to be an accurate judge of his own behaviour or becomes another Nero or Caligula.

Fortunately our managers and CEO’s don’t quite have the power and privileges of Roman emperors, but they often run mad in their own smaller ways. This is especially true if they believe their own myths about their “open door policy”, or “speaking their own mind and expecting everyone else to do the same”. One of the lessons I took from the Deep Dynamics of Agile Teams course I helped organise a few years ago was that figures in authority cause resentment when they do not recognise their own rank. Behaviour which is acceptable between peers, can be inappropriate when coming from a high ranking individual: for instance gallows humour about the likelihood of redundancies is okay amongst work colleagues, but in extreme bad taste coming from a CEO.

I imagine Harry, Clarke’s fictional CEO, to be someone lacking Julian’s astuteness; he has come to believe what is implied by the behaviour of his subordinates that he is a particularly witty, interesting, and wise individual who’s views everyone is eager to hear. I would expect a Bastard CEO like Harry to

• talk the most and for longest during meetings avoiding soliciting, listening to, or giving much time to other’s views or questions
• make inappropriate jokes about other’s abilities, timeliness, or diligence (a joke about installing closed-circuit cameras to stop people slaking off for instance, would be great for demotivating a stressed-out development team)
• organise meetings (or more likely get his PA to do it) and turn up very late, or not at all. After all, no-one ever complains and Harry’s time is more important than everyone else’s time.
• lecture others at length and in detail on how their jobs should be done, without any regard for the other’s skills, experience, or actual productivity
• Blatantly appropriating other’s ideas as his own by copying entire emails or documents and signing them “Harry”, after-all when he owns the other person that person ideas are his own. Besides he probably inspired them anyway.

The corrupting influence of power is often about losing basic social feedback. Finding ways to give the individual feedback on his or here behaviour can be a way of making working with them at least tolerable. It can be a dangerous game though; sometimes it’s best to just stay out of the way.

Tuesday, August 19, 2008 | Permalink | 0 Comments

Mocks considered harmful

Some time ago I tired of using JMock. I’d come to realise that it was badly affecting my production and test code. I have since seen these problems consistently repeated in heavily mocked code-bases: these include incorrect production code with passing unit tests, hard to change production code, functional object decomposition, too many classes, hard to read tests, mammoth test set-ups.

Concerning mocks, stubs, fakes, test doubles

Martin Fowler’s Mocks aren’t stubs essay clearly explains the distinction between Mocks and Stubs, and the associated “Interaction-based” versus “State-based” testing. He now uses Meszaros’ terminology of “Test Doubles” to mean any object that a test substitutes for a production object and Fakes which provide completely functional but unfit-for-production “Test Doubles”. I am not going to use the Meszaros: I’m uncomfortable with “Double” as being an unobvious term, preferring “dummy object” (I would use “fake” if it hadn’t been taken); I don’t think the distinction between stubs and fakes is important or, in practice, clearly defined.

Mocks and stubs are both “dummy objects”. The distinction is important as they tend to encourage different styles of testing and production code. With mocks you would set up your expectations of its interaction with the production code, then run your test; typically integration with xUnit ensures that the expectations were met. Stubs are simple drop-in replacements for production objects, supplying canned answers to various operations. Mocks invariably come from mocking frameworks, while stubs are typically hand-rolled.

Mock objects come packaged with their own ideology: the plausible belief that classes should be tested in isolation and in terms of the way they interact with their collaborators. This is Interaction Based Testing.

Classically we would use production objects where possible, only stubbing out objects which live on the edge of the system, such as database access code. Tests would be written in terms of what is different after running the code under test, hence the retronym ‘State Based Testing’. Any interaction testing, such as checking parameters sent to the database, is done by recording method calls and arguments and checking the results by old-fashioned xUnit asserts.

Mocks make hard to follow tests

Back in my mockist phase I would often return to some tests, and be surprised at how much difficulty I had following my own test code despite the (specious) elegance of JMock’s fluent interface. The unnatural ordering of actions in a mock tests doesn’t help: mock test inverts the order of cause and effect. In a classic test the order is

1. set up the environment
2. run the test
3. check what happened was what we expected to happen

In a mock test it goes

1. set up the environment
2. set up the checks for what will happen (expectations)
3. run the test

Putting the “assertions” before running the test violates the way my brain expects the universe to operate: I’d normally expect to check what happened after it occured. Also setting up the environment often merge into the test expectations blurring the purpose of the test. Mock tests tend to come with a large amount of setup code, the sheer volume of which hampers readability.

While mock-code is hard to read, it is not correspondingly hard to write, and so abstruse code is encouraged.

Wrong code that passes the tests

Mock tester writers use more mocks than classicists use stubs. This partly because of the mockist philosophy of testing each class in isolation, and also because the existence of a framework attracts its use (while stubs tend to be hand-rolled). The risk with dummy objects is that they can embed incorrect assumptions about how the real code operates. An easy example is production code assuming one based indices or while the dummy assumes zero based.

While test-driving heavily mocked code we often needed to fire up the debugger – we had a bunch of passing unit tests, but the functional tests were failing.

Mocks hamper refactoring

Mock tests concern themselves with the behaviour of the class under test – how its objects interact with its collaborators. A mock test is all about what methods are called, and with what parameters on the mocks. The tests are concerned with implementation rather than results. Common refactorings such as ‘move method’ break these tests, rather than being supported by them.

On a recent project the first stage of a refactoring was often a purge of the test’s mocks so that it can support the changing implementation; as a side-effect we invariably rendered the test more readable and smaller. This does increase the cost of many desirable refactorings above a level consistent with adding functionality. Tests should lower the cost of change, not increase it.

Mocks encourage too many classes

There is something about Mock tests, often aggravated by dependency injection frameworks and a knowledge of GoF design patterns that tends to encourage Functional Object Oriented Programming, aka Treating Your Verbs as Nouns. At the height of my mockism I was once writing some code to convert TIFFs to PDFs by shelling out to tiff2pdf. As far as I remember, the process involved a ‘LocateTiffToConvert’ object, a ‘CreateUniqueFileName’ object, a ‘ShellOutToSystemCommand’ object, a factory for configuring the objects, and I still needed something to coordinate the process¹. Each was thoroughly tested, but it’s way too much code for a simple action.

It’s not just me, I frequently see this violation of simplicity in mockist code-bases. It can make things horribly difficult to understand, both by the sheer volume of classes involved and its tendency to obscure the domain with technical concerns

Disclaimer

Nearly all my experience with mock-objects has been with Java and JMock. I have used Ruby’s Flexmock a bit and find it more palatable: I suspect that this is because Flexmock is really at least as much a stubbing framework as a mocking one; also coding in Ruby is always more palatable than Java.

¹ I also wasn’t pairing, being the only programmer on the project. Pair programming – may help prevent you coding like a tit.

Labels: Interaction Based Tests, Mock Objects, TDD, unit tests

Friday, August 15, 2008 | Permalink | 1 Comments

Triple Programming

A question that came up during some training the other day was “if two people are better than one, wouldn’t three be better than two? Why not triple programming?”. You can come up with all sorts of reasons against 3 people coding on one computer, but real the answer is that we tried it and it didn’t work. XP is not built on a set of theories: the practices are things which have been tried and found to be successful on real projects. Beck once said that all he did was observe Ward Cunningham and write down what he did.

Friday, August 15, 2008 | Permalink | 0 Comments