There is a big difference between writing unit tests that test code that has already been written, and test driving your code by only writing code after you have failing tests. One of the problems I had when I first started trying to teach myself TDD was that I would start by writing the class, and then figure out how to test it.

But this is backwards. The problem is, when you have never done any unit tests, and you don't know the API very well, it is hard to just write the tests first, because you have no idea what a good test should look like. You've got no experience.

In the tutorial presented, you test drive the code. There is an initial test checking if the board is empty. It took me a long time to realize that you only write the code you need, breaking all the rules. For example, if I am making a list of some kind (because I need one for the code, not because I've already decided on an architecture), it might go like this...

//psudocode
testNewListIsEmpty() {
   List list = new List();
   assertTrue( list.isEmpty() );
   assertEquals( 0, list.size() );
}

To make this work, I would code a class as follows:

class List {

   public boolean isEmpty() {
      return true;
   }

   public int size() {
      return 0;
   }
}

I can't speak for anyone else, but this was the hardest part for TDD for me. The above code doesn't do anything. It doesn't store any files, and yet, it is the simplest code needed to make the tests pass. I felt really silly writing code like this, and in fact, it is silly, but only for this example.

Learning to take small steps only adding what you need may seems strange, but when you begin to tackle a problem you have NO IDEA how to solve, you'll be surprised at the the clean, easy-to-use code that can come out of this.

So do your best, and, just for fun, instead of deciding you need interfaces, just write ONLY what you need.