55: Confessing Your Naivety

Leading with follow-up, Jake touches on his experiences with developing a WatchKit after having talked to David, how he’s fetching the content for his glance, and how the Swings analogy made him rethink the way he was trying to lay out his views (and thus making his efforts more successful). After getting nostalgic about a listener-submitted Codewarrior mug, Jake talks a little about the various Steve Jobs biographies he’s read, before touching on some assert related feedback. This leads Ben to pose the question about whether you should leave asserts on, or remove them for release code. The couch discusses where people use asserts, and in what cases you might actually want to ship asserts rather than displaying an error. Moving on, Jake asks if Ben has any opinions on testing, and this leads into a discussion about unit testing, and what exactly a unit test should cover. From the conversation expands to cover various other kinds of testing, like integration testing, and UI testing with UI automation. As they start wrapping up, Jake mentions that the bit he likes about unit testing is that it makes him think about the structure of his code, which Jelly believes he already does. In fact, he believes that if you’re relying on testing to structure your thinking, you’re doing it wrong. This prompts Ben to ask about how Jelly approaches his code, which Jelly answers by roughly describing his process when he built Static Tables. Laying out blank classes and methods to create a basic structure, fleshing them out, then writing an example app for testing. Finally, Jake adds that Playgrounds are what got him started on unit testing in the first place. He loves the concept of code being executed as he’s writing it, but the lack of external frameworks lead him to trying out unit testing.