Wednesday, 2 September 2015

Connect Four Kata Run Through in Java | Part One

Hello and welcome to the first kata run through on the Agile Katas blog! In this post, I will be running through or performing the first story in the Connect Four Kata, using Java as my programming language of choice. If you want to follow along with the kata, you can find it over at Agile Katas Connect Four Kata.

Getting Started

First things first- I am using my project template that I use for all katas that I perform- this is a simple basic gradle project with a few choice dependencies included- namely Cucumber-Java, AssertJ, and JUnit. I don't tend to use anything else for simple katas, but may include other dependencies depending on the story and functionality I am working on. I am also using IntelliJ IDEA as my IDE of choice. 

The First Story

Because we are using BDD, our first test is the acceptance criteria of our first story. We create a feature file that includes this information, and we have some executable documentation so we know when our task is finished. For Connect Four, this will look something like this:

The Stepdefs that go along with this feature file will look like this to begin with:

The implementation of these Stepdefs will change considerably depending on how you decide to tackle the problem. You may want to do a little bit of upfront design at this point, choosing what solution you want to use from analysing the requirements at present and possibly in the future, or by what you want to practice with. I have decided to go with an approach that utilises a single class to begin with- the Grid. This means my filled-in Stepdefs file looks like the following:

The Grid class doesn't contain anything except a (possibly definitely fluid) API at this moment, and it looks like this:

Usually this is where I would start to really test drive the code out using TDD, but I'm going to try something new this time and only use the BDD to ensure the behaviour is as expected. The idea is that if you work entirely from the BDD, any changes you make to the implementation of the feature shouldn't cause the tests to break, maybe them less fragile and brittle. This should work for simple classes and simple cases, so this Connect Four kata should be a good test of how well it does here- and if we decide to scale the kata up into a bigger project, we'll be able to see how well pure behaviour driven development scales.

After a very quick implementation, I end up with the following Grid class:

This implementation isn't the best code- it's quick and dirty but it gets the job done. Part of this is because our first instinct should be to get the tests to go green- once we have met the behaviour we have delivered the value for our customer in the short-term, and have something that we can deliver now and improve upon later. This is easier to do when the quick and dirty work only takes 5 minutes like it did here. The other reason is because I have a fairly strong feeling that the user story we just implemented didn't have all of the information we needed for our real solution- so getting it to pass and moving on before trying to refactor it nicely is a good idea- the implementation is probably (definitely) going to change in the next story.

Conclusion

And that's effectively it for the first story. At this point we can go back and refactor any of the code that we're not happy with, safe in the knowledge that any changes we make are covered by our acceptance criteria tests- and as long as they stay green, we know our product owner will still be happy with the behaviour. I won't be performing any refactoring at this point, as I have a sneaky suspicion that this implementation won't stand up to future requirements, and refactoring effect will be better spent after implementing those. 

Stay tuned for part two, where we implement the second story and give the first lot of code a much-needed refactor.