When TDDing, I see info on using interfaces, but how do interfaces get created through TDD? How do you unit test your way to an interface?

Interfaces and TDD

• You have some existing code that has a concrete dependency on something and you want to remove that relationship.
• You are working on new production code, taking a mockist approach and you want to create an object, inject dependencies represented by test-doubles that implement interfaces that do not yet exist.

@GBGames goes on to write (remember, this was in Twitter, so I left the abbreviations and such as is):

Game uses HardwareLayer. HL used libSDL but don’t need SDL for unit tests so I wanted IHL for a mockHL. But how to get IHL? Most info I find assumes interface exists or class exists to extract interface. I feel like I’m trying to do 2 things at once.

This additional information suggests something like the following:

@GBGames suggests using an IHardwareLayer to fully get rid of libSDL, which is a fine approach. Another approach is testing the HardwareLayer directly (with unit tests on the HardwareLayer) and passing in an adapter to libSDL (basically an ILibSdl):

What are we Testing?

When using TDD to test a class that depends on an interface that does not yet exist, how do you go about doing that?

• What methods exist in the interface
• How will the class under test use that interface.

• Create interfaces
• Add methods to those interfaces needed to add functionality
• Set expectations on the use of those interfaces

• The Hardware layer, apparently, does not yet exist.
• By extension, the interface does not yet exist.
• When writing the real hardware layer class, it will ultimately have to implement all of the methods in the interface created while TDDing the game class
• Writing the actual hardware layer class will require TDDing it, and passing in an ILibSDL class. This is not strictly necessary, but if you want to test the HardwareLayer without using the real lib SDL, that’s your best option.

Now to get more concrete

• Creating a game properly initializes the hardware layer
• Creating a game properly acquires some kind of game configuration information, which is used to configure the hardware layer (e.g., preferred resolution, color depth, anti-aliasing, ...) (Do you see that even these two test categories actually suggest more than just two classes if you consider the single responsibility principle.)

This is enough to start to express my intent. Almost time to start with something.

• One assertion per test?
• TDD or BDD (At the very lest, looks like we’re staring outside in)
• ...

Test 1: Initializing

package com.om.example.gameandhw;

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;

import org.junit.Test;

public class GameTest {
  @Test
  public void itShouldInitializeHardwareLayerDringGameConstruction() {
    IHardwareLayer layer = mock(IHardwareLayer.class);
    new Game(layer);
    verify(layer, times(1)).setResolution(1024, 768);
    verify(layer, times(1)).setColorDepth(8);
  }
}

• On the first line, I had to create and interface IHardwareLayer, no methods.
• On the first line, I also had to stop to statically import the mock method.
• On the second line I had to stop and create the Game class.
• On the second line I had to stop and add a constructor with a parameter (the injected IHardwareLayer, for which I use the Mockito library to create a test-double, which I am using as a Spy)
• On the third line I had to stop to add the method setResolution to the IHardwareLayer interface.
• On the third line I had to stop to add the static import of the verify method.
• On the fourth line I had to stop to add the setColorDepth method to the IHardwareLayer interface.

(Trust me, it too much longer to type that list than to do the work. The actual work was well under 30 seconds to do all of that.)

package com.om.example.gameandhw;

public interface IHardwareLayer {
  void setResolution(int widthInBits, int heightInBits);
  void setColorDepth(int bitsPerChannel);
}

package com.om.example.gameandhw;

public class Game {
  public Game(IHardwareLayer layer) {
    layer.setResolution(1024, 768);
    layer.setColorDepth(8);
  }
}

Now I have no idea if this is even beginning to make any sense for the original problem. This is where having a pair partner with expertise on the game requirements (and maybe some idea about this libSDL) would greatly help.

Notice, however, that as I try to write the Game class, I am adding methods to the IHardwareLayer class AND figuring out how the game will interact with those methods.

Hope this helps GBGames. I also hope to see some discussion in the comments section.

Brett