Tic Tac Toe computer player algorithm via TDD
Some time ago I had an argument with another team member - he was claiming that Test-driven development (TDD) was not applicable to our application. He thought it would be more efficient to rely on manual or E2E testing instead. I disagreed.
Without going too much into the details, the core of the application we were working on was a graph-traversing algorithm with some amount of mathematical calculations. It was painful to test on a system level as the number of possibilities was huge and it was not easy to put the system into a particular state to check specific conditions.
I thought that thorough unit-test coverage, and, ideally, TDD would be more efficient, but was not able to persuade my colleague. At the end of the day, I started to doubt if I was right.
Challenge was accepted, so I tried to do something more or less similar (though simplified) - implementing a Tic Tac Toe computer player logic via as pure TDD as possible.
Long story short, after some time I managed to get the result I wanted, and there were some takeaways I wanted to share:
The final code may be seen here:
https://github.com/senpay/tictactoe_tdd_java
Without going too much into the details, the core of the application we were working on was a graph-traversing algorithm with some amount of mathematical calculations. It was painful to test on a system level as the number of possibilities was huge and it was not easy to put the system into a particular state to check specific conditions.
I thought that thorough unit-test coverage, and, ideally, TDD would be more efficient, but was not able to persuade my colleague. At the end of the day, I started to doubt if I was right.
Challenge was accepted, so I tried to do something more or less similar (though simplified) - implementing a Tic Tac Toe computer player logic via as pure TDD as possible.
Long story short, after some time I managed to get the result I wanted, and there were some takeaways I wanted to share:
- I didn't see any evidence that TDD is not applicable for such tasks
- I wasn't able to follow 100% vanilla TDD (there's some code that was written without writing test-first, specifically Main.java). Well, that hardly was a surprise
- Lots of unit tests allowed me to have nearly 100% test coverage
- There was no (subjective) feeling that TDD allows me to move faster, but
- Manual testing didn't show many issues, which may indicate that TDD has a positive impact on external quality. So time was saved on testing -> bug-fixing -> retesting, and
- As soon as I started to change things (refactoring, reimplementing wrong logic, fixing bugs, improving algorithm) unit tests that I had were invaluable.
The final code may be seen here:
https://github.com/senpay/tictactoe_tdd_java
Comments
Post a Comment