The Butterfly Effect in Mobile Development

Our story begin on Friday night.

Me and my wife got ready for a fun movie night, the pizza was hot and the wine was cold

and then the phone rang.

Hey Ido, we need this very very very small fix in the mobile app for like tomorrow morning. can you make it please, be our savior, the customer really really really need this fix…

Well, ok I answered, I will do it right away.

I sat down by the laptop, “This doesn’t sound too complicated”, I thought to myself.

The work was almost done, and all I wanted was to get back to my movie night, it wasn’t too late for that.

And than I heard an inner voice: “It is such a small fix, just do some manual tests and lets call it done, you can skip unit tests just this once”

And that is what I did.

Run few manual tests to see everything works as it should and pressed the big red button “Release”.

Some time later I found out how this small change caused a massive issue that my manual tests did not discover.

If only I invested the time in unit tests, this would probably did not happened.

When we write unit tests, it force us to think on the different flows, since we see the code that leads to each flow, compared to “black box” or “manual testing” where we need to know about everything.

And as you can see, I do have unit tests:

[09:35:14]: ▸ Test Succeeded 
+--------------------+------+
| Test Results              | 
+--------------------+------+ 
| Number of tests    | 5794 | 
| Number of failures | 0    | 
+--------------------+------+

Yes, 5794 (at the time writing this article)

Unit Tests, for a mobile app? Seriously, I can just test it manually in 5 minutes

This might be true if the mobile app is small, but as the app gets bigger in code base and features a complete manual testing cycle can take several days.

It seems to me that unit tests for mobile app are not a consensus yet.

Assuming most of us already working on existing app or code base, the first challenge is adding unit tests for the first time.

Unit tests has some prerequisites that takes time to implement, but it doesn’t mean that the case should be cover all or none.

The code might not built for testing, and changing it can be a little tricky, but still it is possible to start small.

The main pattern I use to allow components to be tested is Dependency Injection.

But writing tests takes time

Yes, it is true.

Writing tests takes time, sometimes it can even take longer than the time it took to write the code it is testing.

But it is a time well invested in the stability of the future (and our Friday nights).

Every new test added saves the time and worries of manually testing this case again and again on every future small change.

Instead we just let the unit tests run and provide us with the confidence we need to keep on adding new features quickly.

You want to tell me unit tests can save me money?

We all know that time is money.

When an issue is found by our unit tests, it is caught in an early stage of the development, what usually means it easier to fix.

Comparing an issue found by unit tests to tracing an issue found by an end-user after the app was released, or even compared to an issue found by the QA team, unit tests are definitely much more faster to trace and fix.

So unit tests saves time which also means they save money, since software engineers and QA engineers time also cost money.