Few months ago in the office we started a discussion about testing.
The original topic was “how to implement a continuous integration/continuous delivery workflow”, so “how to test” became immediately a requirement and a parallel important topic.
My suggestion was to start coding in TDD of course, but like every office we had a lot of legacy code to deal with.
In order not to be stuck by that, we decided temporarily to focus on new (or almost new) projects and apply it to them.
So the point became to find a way to have all the developers, regardless on the seniority and the project, on the same page about the topic.
After the first implementation of the game, my friend and I compared our versions.
He focused on the deck model instead of the dealer like I did.
This simple choice drove his design to a complete different path.
He put a lot of effort trying to replicate a realistic deck, implementing the shuffle logic and making impossible to draw the same card twice.
This hypotheses never came up to my mind because I knew that in the real game there are multiple decks in order to make almost impossible for the players the calculation of the drawn cards.
The Tiles are central in the game exactly like the Pawns. Naturally refering to Tiles I’m talking about the map in general, the board where our little pawns have their conflict.
I think that to define a map, or in general the level design, is one of the big deal projecting a game. The main Character (or units depending on the game) is important, the skills are important, but if the level design sucks all the experience sucks no matter what.
For me Super Mario Galaxy is a master piece because of its level design.
So I was sure that with designing bad maps the whole game would have been a disaster.
I decided to keep things simple and to introduce more possibilites after a gameplay test.
When I developed the pivotaltracker plugin to extract our backlogs (here the post), instead of create a mock application to use it, I gave the library to my colleague so he could integrate it in the real application that my frontend application would have used to retrieve all the backlogs.
Everything went well until the application tried to parse the stories in the final contract, then the application crashed miserably.
I and my colleague worked side by side:
The first thing I did was to run my test: all passed.
So I checked the response of the pivotaltracker API, maybe they had changed something: nope, the response of the API was exactly what I expected to receive.
So what happened?
Why my test didn’t represent correctly the real situation?