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

Yesterday I decided to have a look at working with XNA and C# to broaden my knowledge of other languages and Frameworks. After having a little dabble I realised the potential for quick cycle games in XNA. A lot, if not all the graphics code is wrapped up and kept away from you. I'm not too sure whether this is a good thing, although I have seen some samples online where people can access the graphics more directly.

Anyway I had a look online and found a small tutorial on:  http://www.xnadevelopment.com/ that showed how to add sprites and input from buttons and what not. The tutorial was directed toward beginner programmers which got a little frustrated but it allowed me to get a grip with the XNA framework. 

Below is a video of something I created in XNA, It's just a simple scrolling background and player movement. This type of thing can literally be made in no time at all:

The main reason for me taking such an interest in XNA and C# is that I was hoping to create a small level editor which could be used for placing my models in the Road to Eldorado game and other future games. That way I could Export it to XML in the exact format that is needed for importing straight into the game. I thought about it and I had seen a few examples of editors that used Windows Forms and XNA together. After searching the net I realised that this is not as easy as I first thought. Having both together seems like hard work and would require me to expand my knowledge of both Windows Forms and XNA largely before I could attempt this.

I think I will probably end up just making a level editor in C++ and just adapt the game to create, move and resize entities on the fly. I still am more than likely going to proceed in learning about XNA as it really interests me and the idea of being able to eventually play one of my games on xbox is pretty cool. 

Till next time :)