I’ve been pairing for over a decade. I’ve witnessed and tried all kinds of things shoulder-to-shoulder with all kinds of pairing partners. Through the years I’ve witnessed a single consistent misfire while pairing. We don’t understand our roles. As professional problem solvers we gravitate towards actively solving the problem at hand.
About a month ago, I facilitated the first event as part of the Source Allies external mentoring program known as Source Allies University (SAU).
It was an interactive forum and networking event designed to:
- Cover basics and explore new tricks of Test Driven Development (TDD) in Java
- Create new code & refactor existing legacy code via TDD
- Code through a sample project for hands-on experience
If you have ever practiced test driven development (TDD), then you are probably familiar with the TDD mantra – red, green, refactor. I’m a big proponent of TDD, but I think the TDD mantra is missing a fourth step.
Once you catch the automated testing itch you want to write test for everything. But should we use the same strategy for every piece of software? The conclusion that I’ve come to is no. While I’m completely committed to the practice of TDD and aggressive test coverage, I’ve found that legacy software needs to be approached strategically.
Pair programming is a technique where two programmers work at a single work station. One person “drives” or has control of the mouse and keyboard. The other person “navigates” or keeps track of where they are and where they are headed. This is a perfect environment for teaching and learning to occur.
One of the primary principles of unit testing is to test a small piece of functionality in isolation. In order to achieve this, mock objects are often necessary. Historically using mocks could be quite painful. After using several mock frameworks, my favorite by far is Mockito.
In this tutorial we will walk through examples of the most common features of Mockito. My sample project can be downloaded here.
Interfaces and Implementation
Some mocking frameworks only supported mocking interfaces. As a result our projects became bloated with useless interfaces that were only used for testing. Mockito creates mock objects with interfaces or classes.