Minesweeper: Board Visualisation

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. 

TDD and 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.

​

So What Should I Test?

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:

BoardVisualiser and Dependency Injection

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.

GetSquareOrigin

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 :)