The first part of a fresh look at testing
For something that is thought to be precise and unambiguous, the whole subject of software testing tends to be hilariously unclear. I’ve had a deep interest in the subject of automated testing for iOS for years now, and found that if you ask 3 people what the point of testing is, you’ll probably get a dozen different answers.
For . . .
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 . . .
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 . . .