testing

Core Data and Unit Testing haven't always been the best of friends ⚔️. Core Data is all about persisting. Unit testing is all about forgetting. Here, we look at how they can work together with the help of UIKit to ensure that we gain the confidence we need to ship an app.

An uncomfortable truth is that praising firefighting developers might just be leading to more fires. Here, we look at why needing firefighting developers is a sign that your processes need to be improved, as avoiding fires is better than managing fires.

We want to test that our network stacks can make network requests as intended but without actually making those requests. Here, we look at how to split our networking stack into components to allow easy unit testing.

When I first created ConvenientFileManager [https://github.com/wibosco/ConvenientFileManager] I didn't add a unit testing target - what can I say, I was young(er) and foolish. Recently I decided to rectify this grievous error and added a unit testing target. After writing the tests I pushed them

Cohesion is important for your application. Each unit of work should have a clear purpose and clear area of responsibility, this is known as the Single Responsibility Principle [https://en.wikipedia.org/wiki/Single_responsibility_principle] (SRP). If you find that you are working on a method/class t

Dependence injection (DI) is a useful technique to have in your unit testing toolbox. It's were we take implicit dependencies that our method/class rely on and make those dependencies explicit. It's especially useful when writing unit tests as it allows us to avoid using the black magic of m

If you have ever written a unit test, chance has it that you used either black or white box testing techniques to determine what that unit test was testing. In this post I want to explore both these techniques and look at when we should be using them. Black-box techniques Black-box testing i

I find it surprisingly hard to get new developers to really engage with unit testing but then when I think back to when I had just graduated and what I thought about unit testing: I'm here to write code, not to test! I shouldn't be surprised. Unit testing works slightly counter intuiti

iOS hasn't always been the most unit-test friendly environment, but since Xcode 4 this has changed - a lot of the setup has now been automated away for us. These improvements make adding unit tests to your application easier than ever. However, the question remains: What should be tested?

Bugs only exist in software because we as developers introduce them. We don't mean to introduce them however there is no denying that they exist and that we've all come across them at some point in the software that we use. Thankfully there are a range of testing techniques that we can emp

When writing a class or method, the way that I view other classes that want to use my class is as my enemies (even if I’m writing the other classes!). That might should dramatic but I take the approach that what ever is going to use my class might not properly understand the class and feed it junk.

On a project recently I had to develop some model classes that would be populated upon creation from a web service. A requirement was that once the model object where created they should not be altered. As I wasn't the sole coder on this project I decided to defend these objects and ensure that

Both Boundary Value Analysis (BVA) and Equivalence Partitioning (EP) are test case design strategies in black box testing. As with any mildly complex piece of software it is impossible to exhaustively test it so we must ensure that the tests we do perform are as efficient and effective as possible.