Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of 'getting things done'.
We were to build an implementation of Conway's Game of Life with an emphasis on unit testing and Test-Driven Development (TDD).
When we got started we broke up into pairs (pair programming) where we would switch off between driver (the person behind the keyboard) and navigator (the person who dictates which way we go) for 45-minute sessions.
We attempted to start by creating a grid with known cells so we could test it and the session ended before we could get anywhere. We knew the first session was a throwaway because we would be figuring how the game worked, the rules, and where to start. My partner was at the event for the first time as well, so we spent a lot of time spinning our wheels trying to figure out what we needed to do.
In this session, the rules were switched up and one person would write a test and the second person would write the method and then switch roles. This time I paired up with someone who has come to the event before and he wrote a test to check if a cell is alive. I was like "Wait, what? Don't we need a grid first to test it against?". The discussion started from there and I was like "Oh we are creating an infinite grid where we are tracking only the live cells and we don't care about the dead cells", I had my mind blown by how over complex I was making it in the first session. I then proceeded to write the method that would satisfy that test and some other things before the session came to an end.
Test-Driven Development (TDD) seemed so odd to me and I was so lost as to why we would even write the test before writing the method. It was tough to break my habit of writing a method first, then write a test for it, and seeing the test pass. I can see why the TDD approach is a good habit to pick up. It helps you write shorter code that would pass the test and your methods would only do one thing that way you could test it and know if you break your method in a future refactoring. I'm going to try and implement TDD in my next project to see where it would take me and if I approach projects differently in the future.