Ok, gonna make this quick, or else I’ll never publish it.
I just listened to a great episode of Fatal Error podcast on testing.1 Chris is clearly a consistent unit test writer and did a great job laying out the whys of testing and some basic approaches. Soroush did a great job as the less consistent test writer and laid out some great reasons why testing would be helpful. Together I appreciated a few of their strategies for getting started.
I know that Chris in particular felt like the episode was a mess, but honestly, it was really, really good. More to come will be welcome, but this episode struck a great balance of nitty gritty without getting bogged down by nailing down every. single. term. and. concept. which in the testing conversation is a serious risk.
That was just throat clearing. The point of my post is to describe how I get bogged down in trying to add tests to my current codebase:
- Our codebase is a mix of Objective-C and Swift.
- I fixed a bug today. The fix involved UINotificationCenter. So there were a few places that I was just not going to even try to test, i.e. “did the class get the notification?”, “Did the class call the right method when it got the notification?”… But the class called a protocol method that behaved differently depending on whether I passed an object or if I passed
nil. That seemed testable.
- So, then I started to think about writing a test. And I started down this mental path:
- I need to create an object that conforms to the protocol.
- The method in question does not actually return a value, it just calls a method on our analytics singelton if the object is present.
- So, I guess that I could rewrite this method in the class that conforms to the protocol, so that it calls a returning method that indicates whether it should call the analytics method. OK.
- Then, we are writing all of our Unit tests in swift, no problem, creating an object that conforms to an protocol is no problem, right? No, I don’t think so. But how do I know if the other method is called? Well, I’ll figure that out in a minute.
- Oh, and I’ll need to figure out how to call a private Obj-C method from swift. If the test were objective-C, I would just write an inline
(testable)category in the Unit Test File, but how to do this in Swift? 2
- AAAaannddd… I’m done. This method is simple and obvious enough… No need to test it…
Some of these things are definitely only problems because I don’t write tests often enough. I’m sure they would strike many as trivial problems that are just a part of writing inter-operating Swift and things that are just learned with practice. I agree. It’s just as raw (and vaguely embarrassing) a description of my mental process as I can write.