Last year, I wrote a post about the problems with code coverage as a metric, and left the topic as “to be continued”, saying that I had some ideas for a better approach. Well, it's taken long enough, but here are the first pieces in that objective to evolve a better way to create and measure well-tested software.
What Makes Good . . .
Injecting unique, mutable and persistent property values
Update: The original approach and sample code in this post have been modified slightly — instead of every Injected instance defining its own storage for injected traits, the Injectable struct instead defines global storage for all Injected instances. This is to allow let / constant struct instances to be injected with a stored trait without . . .
While I would guess that fewer iOS developers are concerned with Dependency Injection than say, Java developers, the concept has gained more steam on the platform as the practice of unit and integration testing has increased.
In short, Dependency Injection (or DI) consists of:
Making your structs or classes depend on . . .
Good first impressions, but some significant rough edges
So, I spent a bit of time on the weekend playing a little more in-depth with the new UI Testing APIs in the Xcode 7 beta 2. Please note that this is beta software, so many of my observations may not be true for the final release or future betas.
UI testing feels like an effortless and natural part of the . . .
One of the areas I’m focusing on right now is the subject of testing. Automated testing in general, and at the moment, unit testing specifically. And one observation keeps jumping out at me:
Code coverage is a terrible metric
What is code coverage? Briefly, it’s the number or percentage of the lines of code in your . . .