Today I was surprised, that a lot of devs miss negative test cases

Let’s take a look at example of testing simple class:



Nothing special, yeah?

Let’s try to make a full test suite for this class.

Step1. Determine test cases for this method


  • add object @“test” and expect that model.objects contain this object.
  • add object @“test” and expect that model.objects count = 1.
  • new instance expects model.objects != nil
  • new instance expects model.objects.count = 0

That’s great, but not enough, Xcode tool will tell us that we have 100% full test coverage for this class, but in reality, it’s not enough.

All sense of testing is avoided problems when something goes wrong but we keep testing only “good cases”. Why?!
Let’s go through negatives.

  • add nil and expect no crash

If we have a public method we must be sure, that it will not crash the application if any input parameter is invalid!

You can say – “It’s not a problem for me, I will check it in another class before calling this method.” When you will add a new class that will work with this method directly, and you forget about this? Or you plan to copy-paste this checks everywhere? That smells bad…
You can live with it, but it’s not great when your app crashes and you get bad reviews.

Step2. Write code


The first thing that you need to do with unit testing it’s a catch error before QA team and application users.

I strongly recommend follow with structure “Given-When-Then” to keep your test case code logically ordered and consistent.

And meanwhile, I prepare the post about proper work with tables and collections you can check daily updates in my repo.

More about unit testing you can find here:

Categories: Unit Testing

Oksana Kovalchuk

Passionate IOS Developer

Related Posts

Unit Testing

Specta is dead?

Today I opened my previous project and just ran all unit tests. I was so proud that they working with new XCode, even with some warnings.   But waiiiit….they all are passed. I just wrote Read more...