Writing unit tests for Minesweeper game

Writing unit tests for Minesweeper game

Yesterday was quite a productive day to conclude the refactor project. Especially I venture into the most sacred territory of any good software - Unit testing. Here are the screenshots of test coverage taken before and after writing tests

Coverage at just 4.4%
Coverage at 85.6%

It was overall a big win. Especially after I felt so much burnt-out and demotivated during holidays. The fact that I didn't actually use MVVM or VIPER didn't keep me from writing comprehensive unit tests. Most of the views were created programmatically so there wasn't nasty crash due to uninitialized views or other cases.

Here is the list of some lessons I learned while writing code for easier and reliable unit testing.

  1. It doesn't matter which "best" software architecture you're using as long as your code is stable, unit-based and reusable
  2. Dependency injection is the major component. As much as possible try to pass in parameters rather than depending on top level variable, or worse - Universally global or singletons
  3. Don't get obsessed over code-coverage. It doesn't say how well your code is tested. Think in terms of how much logic has been tested and does it cover all the edge cases?
  4. Unit tests shouldn't burden themselves testing views irrespective of how much test coverage you may lose. This is where UI testing comes into the picture
  5. Do not write tests to "test" constraints. You don't really want to test code written by Apple engineers
  6. TDD is hard - I am not ashamed to accept the fact that I never had a good luck with it
  7. Start with failing tests - Let them fail and eventually build on top of them to make them eventually pass
  8. It's ok to keep some of the methods untested which falls outside your territory. Examples could be method stubs in AppDelegate and init?(coder aDecoder: NSCoder)
  9. Final thoughts - Unit tests might feel like waste of time and resources when "valuable" time may be utilized towards writing a code. But that's not the case, while doing refactor unit tests offer automated way to catch breaking changes without manually performing that operation - Provided you're written comprehensive set of unit tests covering simple as well as edge cases
Before I conclude the series, the full source code is available at NewMineSweeperGame on GitHub. Feel free to give a feedback or any code review suggestions. It will be very much appreciated!