After reading Graham Lee’s Test-Driven iOS Development; (disclaimer: affiliate link) I have (again) adopted a test-driven approach to software developing. Whenever I create a new class I write a bunch of tests exercising the class’ properties. One might question the value of this, because there is not really any reason why those should not work. However, having such a test in place just uncovered an as-yet unnoticed bug I introduced in a project.
Originally the class property in question was going to be set in
init method, so I tested for the presence of the property
after creating an instance of the relevant class. Easy pass. Weeks
later I did something (and forgot to run the test suite). Today I
did something else, and this time I did run them. Hey presto, failed
test. And completely unexpected, because it was the property
exercising one. How on Earth did that happen?
Upon closer inspection I tracked it down to a refactoring, where I
extracted some code from
init as there were now multiple ways an
object could be initialised. The failing code was part of that, and
I realised that it was called from the new
but no longer from the default initialiser. Easy mistake to make.
And had I run my test-suite more consistently, my application would
not have been with a potential bug in the meantime.
What did I take home from this?
- Even Mickey-Mouse-tests are valuable. No test is too small to be useful (provided it’s actually testing something valid).
- The test-suite should really be run after every change. I’ll have to check if I can get Xcode to run them automatically after each compilation…
Update: Since I stopped doing much iOS or Mac OS work, I no longer used Xcode. And I’m not missing it :)