A Practical Case of Mockery

At my university there are two courses in iterative programming, using extreme programming (XP) as a methodology. It is actually two courses in one. The first one is new students who are thrown into a big Java-programming project for the first time. The project would span for eight weeks, where they had a full workday on mondays and have a design meeting in the middle of the week. Towards the end, they have to use their very own time tracking application in a race.

It is important to note that the goal is not to teach the students XP, but to actually teach them how important it is to work together as a team. As far as I know, it is the only course in the world who offers this with great support from the school staff.

Following this course is yet another optional one about coaching these teams of hapless yet jolly fellowship of students. And I became one of these coaches. But that’s not what I’m going to talk about now.

When I was a coaching, I’ve been trying to find some simple way of telling my team on why they should be using mock objects in their tests. I remember that I had a hurdle getting over them myself. My team had it a bit worse as they were fairly new in test-driven development, learning about it previous semester, but they gave this unit testing gig a try.

There are two big reasons why the team will benefit from writing mocks. The first and foremost reason is that tests will become less brittle as they actually will be testing single classes at a time disregarding how other collaborating classes will communicate with it. I’ve found by myself the hard way that when you’re testing several objects in a test that it is atrociously difficult to refactor the code.

The second reason has to do with this tip I from a peer coaching another team:

Whenever your team encounter the situation in which two pair-programmers start to fiddle around with the same class, tell them that they should consider adding an interface for that class. If they’re doing proper testing they’ll realize after a while why they need mock-objects.

If the team didn’t follow the advice it would lead to nasty merge conflicts if the team will continue to edit a class from two different pairs. Forcing them to program to an interface will teach them two things. Intuitively learning what dependency injection means and that you need to create a mock class in order to test against the interface without any outside interference.

Unfortunately, my team was a bit hesitant in using mocks, which was probably due to their inexperience with writing tests. Considering they were new at this testing dealie, it wasn’t until the end of the course when the students had to make their third release and demo it that they realized why they needed every piece of the software development puzzle. Which was also among other things they needed to learn such as acceptance tests and task lists. But I guess we all learn from our mistakes and there were other teams who were more or less successful.