A week ago we had a code retreat at work. This is essentially a day spent away from our normal work in which we can learn about an aspect of software development.

This code retreat was all about Clean Code and Test Driven Development. The day was ran by Chris Sharp who is an STSM at IBM.

The day was a complete success in my eyes. I've already been pushing for people at work to begin reading the series of Clean Code books and this day re-inforced why it is valuable.

I think there were a number of things that people were quite surprised by:

• ​It is actually quite difficult to develop in a strict TDD way. (people often forget the Red, in the Red, Green, Refactor cycle)
  
• The outcome of the code was much simpler and a lot of people agreed that they likely wouldn't have reached that outcome without TDD.
• Software Development is a craft. We tend to get used to churning out code and it can be easy to forget that practice is important.

So those are just a few of the notes that the group had after the session.

I really want to get clean code and TDD brought into our every day work so that we can all benefit from it, although this is going to be a challenge.

I am going to have to lead by example with this, reinforcing it in my scrum's social contract and showing the results.

Finally we are having a second code retreat as only half of the Lab got to go to the first one. I have put myself forward as an "Advocate for Clean Code" in which I will help Chris run the session by going round and giving people guidance whilst they are performing the Kata's.

​Thanks :)

So as mentioned in the README, I have a few stages of development that I would like to take this project to.

The first stage was to simply use TDD to implement the Coding Kata to pass the Tests. The next stage and the one I am currently working on is to visualise the Minesweeper Board using Monogame. 

As I still wanted to progress with practising TDD I decided that I should carry it on throughout the other stages of this development and this brought up some interesting results.

As I began the visualisation phase I quickly realised that I will have to be conscious about which part of the code I test. For example, I decided I wasn't going to test any of the draw functions and these are the reasons why:

• The drawing functionality is so closely linked to Monogame that I would essentially be writing tests to ensure that Monogame is working correctly, which I'm sure Monogame already has plenty of.
• I could test that when I draw a particular square I could then check that against an image to ensure that It matches up perfectly. Of course If I ever changed font, changed background colours or provided any tweaks to the visuals then these tests would need to be re-worked. Not ideal.

​

The advantage of this forward thinking is that I could make clear decisions about what I would test. These are the decisions I ended up making:

Due to the fact that I knew that I had fully tested the Board Class and that if we are using SOLID principles then that should now be "Closed to modification". I Created a new class called BoardVisualiser which takes a Board Class as it's constructor argument which would then deal with purely visualisation of the Board. 

In the past I may have been tempted to just add some Monogame Classes to the Board class and add a draw function to it. By doing TDD that thought never even crossed my mind, which is a great sign that performing TDD leads to better architecture.

As I knew I was not going to test the draw functions themselves, that didn't mean I couldn't test anything that would be a part of the BoardVisualiser class. I realised that I would need a method to find the origin that I would need to provide to the draw calls to say where I would like each square to be drawn. It's this sort of application logic that I could quite easily test. 

I was careful to try and keep this function to use as many primitive types as I could, It would have been fairly easy for me to pass in a Monogame class to this function but that would have put a dependency on Monogame in my tests which wasn't really necessary for this particular function.

Something that is fairly interesting, is that I actually found a bug whilst performing the TDD on GetSquareOrigin function. It was a simple copy and paste error but I wouldn't have caught it until much later on when trying to draw the squares to the screen and by that point it would have been much harder to find.

​Cheers :)

So I've been working on the Minesweeper Kata mentioned in my previous blog post (When I don't have work, or a one year old to entertain) and I've finally got it checked into Github. 

​It is available here.

There are still plenty more pieces of functionality that I would like to add, most of which I've listed in the README on Github. Before doing so I thought I would write a little post mortem of how I got on with the Kata.

This isn't going to be a list of advantages/disadvantages of TDD but more what aspects of using TDD for this worked well for me.

Pros:

• By forcing myself to do strict TDD I believe the end result was much higher quality, there were a few cases where my first attempt actually failed in some not so obvious ways. These would have slipped through the net normally.
• Focusing on the Testing/Requirements rather than just implementing the functionality actually became a bit of a game. e.g. "Hmm, what are the failure cases of this function? What Inputs can I give it to make it fall over?"

Cons:

• Due to the fact that I've not done strict TDD for a while I did find myself having to delete some code as I had started adding more code than was necessary to pass the test I was working on.

Overall I've really had fun doing this little Kata so far and can't wait to carry on adding functionality and plenty more tests to the project. 

​Cheers :)

So we'eve been doing some test driven development at work but not enough to really feel as though I'm getting the most out of it. To improve my ability to write good unit tests and become a TDD star I've decided to start completing some coding Kata's. A term I've picked up recently from the Uncle Bob's Clean Code series of books.

Kata is a Japanese word that is used for a concept used in Martial Arts. The term refers to a repetitive exercise or pattern of movements that is used as a training technique for Martial Arts.

So how does this apply to programming?

Well the terminology has taken off quite a bit and there are now multiple Coding Dojo sites around that will have a list of different Kata's that a programmer can pick up and start using as a exercise to improve their coding.

Personally I'm using the Kata's as an opportunity to test myself using techniques such as TDD or to practice picking up a new language without resorting to some of the boring example programs.

So the Kata I'm taking up is a recreate of the level generation for the Minesweeper game was on the early Windows Machines. You can take a look at the Kata here.

So the main things I'm trying to achieve from this are:

• Improve my Test Driven Development (TDD) skills
• Refresh myself using C#, in particular using Monogame as I haven't used it before.

The Monogame work will actually be an extension, I will first be completing the Kata as is and then extending it using Monogame to add some Visual appeal to it.

​Okay so that's it for now I'll let you know how I get on.

Cheers