What Is Coderetreat?

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'.

The Task

We were to build an implementation ofConway's Game of Life with an emphasis on unit testing and Test-Driven Development (TDD).

The Event

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.

First Session
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.

Second Session
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.

Third Session
The third session was about mob programming where you had a driver and a navigator (every two minutes the roles would switch and we would go through most of the group this way), the navigator could communicate with the rest of the mob about what to write next and the driver could only take instructions from the navigator. A majority of the group voted to do it in JavaScript (JS) and we had some none JS programmers and the navigator would have to talk with the mob about what to do. The interesting part about it was each person had a different approach and they could just undo what the last person did because they would do it their way. It was a very interesting experience for sure and encourages you to communicate better.

Conclusion

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.