Let’s look at how a change to unit testing empowers TDD.
“Uncle Bob” Martin creates strong impressions, with outlandish costumes and black-and-white statements. If you understand that this is his didactic style, you can appreciate him fully. But people seem to enjoy jumping on statements rather than trying to grasp the whole. (Ah, Internet culture.)
I’m referring to the sentence: “You don’t need static type checking if you have 100% unit test coverage.”
This is one of the closing statements from Uncle Bob’s recent blog post, Type Wars. Various people jumped all over this, with much LOL.
Who’s right? Is Uncle Bob right? Are his detractors right? Continue Reading…
I’m always on the lookout for new tools. Are you? Anything that might increase programmer productivity is worth a look.
You know that I’m a big AppCode fan. It saves huge amounts of time. And doing so within an IDE helps me stay “in the zone.”
So I’d love to hear more from you. What are your favorite tools for productive programming? Click here to share your tips!
OCHamcrest matchers are predicates on steroids:
- You can combine them to create expressive assertions.
- They describe mismatches in detail, reducing the need to debug.
But OCHamcrest isn’t just a library of powerful matchers. It’s a framework for creating your own.
By creating a custom matcher, you create a small Domain-Specific Language. This will make your unit tests easier to write, easier to read, and self-diagnosing! Continue Reading…
AppCode vs. Xcode: Which is easier to use for unit testing? Which gives faster feedback?
Back in Xcode 4 days, Apple’s file template for unit tests was awkward and bloated. So I made my own.
Fast-forward 5 years to Xcode 7.3. I’m starting to write Swift. The first thing I want is unit tests — let’s create a new test suite. I look in Xcode’s file template library. Where’s the Swift unit testing template?
Where is it? Apple didn’t provide one?
Fine. I made my own.
Edit: ⌘N for New File does let you choose the language. But not when you drag it in from the Utilities panel! In any case, the resulting file is stuffed with cruft which wastes your time. My template fixes that. Continue Reading…
This is about speed. The more I trust the tests over a section of code, the more fearless I can be with bold refactoring. Fearless refactoring means I don’t spend time checking correctness. That’s what the tests are for! Instead, I can focus completely on good design.
So how can you increase confidence in your test code? Continue Reading…
Fast feedback is the chief benefit of TDD. Even if you’re not practicing TDD, anything that reduces the need to step through code saves a lot of time. For example, if you name your tests well, a test failure can tell you a lot just from the test’s name.
But what if you’re using a mock object? When a test fails, what can it tell you?
A hand-coded mock can tell you as much as you can code. But writing boilerplate gets old, so the reporting tends to be shallow.
And most mock object frameworks generate mocks that simply report, “Such-and-such was not invoked.”
This was also true of OCMockito. Until recently. Here are the 3 new descriptions of verification failures: Continue Reading…
I’ve given you 3 Reasons Why It’s Important to Refactor Tests. But what’s actually involved in refactoring tests?
The definitive book on this topic is xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. It’s a big book, full of patterns and smells. But there are 3 simple steps I take most often.