Unit Testing in iOS
Part 1: Why do we need Unit Testing when developing an application?
Preface
I’m planning to write a complete series of Unit Testing for iOS. You can find finished parts in the links below. Happy reading :)
Part 1: Why do we need Unit Testing when developing an application?
Part 2: My first Unit Tests
Part 3: Quick/Nimble for a clean test
Part 4: How to deal with context
Part 5: Good practices
Part 6: Unit Test, Jenkins & SonarQube altogether [TO BE WRITTEN]
For many of us, writing Test is the most annoying job to do when developing an application. With my writes about UnitTesting in iOS, I hope they will change their minds.
First, let discuss the advantages of writing unit tests during the development of an application.
- First reason: to detect errors in the early stage of the development.
Without Unit Testing, the normal application development process is something like that
Depending on the methodology used by the company, this circle can be more complicated. With this process, errors can be found only when the tester does the manual test. Then, after fixing those bugs, the next release can still contain other bugs or regressions. And later bugs are also be detected after next test round.
In case testers are the clients, they may have a bad impression of your work when they see errors occur. Of course, as a developer, we don’t want that.
- Second reason: to facilitate the debugs
When things go wrong, UnitTest can also help you find out where is the problem more easily. Basically, UnitTest is based on expectation:
expect(condition) else test is failed
Then when you run the test, if the test case is not passed, your IDE will show you what you are expecting and what the real test gives you. So will have the idea why it bugs.
Look at the red message given by Xcode after a failing test:
- Third reason: to make the maintenance/upgrade less painful.
As UnitTest helps you detect errors while developing, it will work also when you have to upgrade or maintain the application. Usually, during the update of application, you will modify the behavior of your classes, your methods to achieve new functionalities. By doing this, old/another feature may not work anymore. We easily forget to check those feature against regressions.
By running the same test case with new codes, you can see if the new code is still retro-compatible with current expected behavior or not. Of course, the expected behavior can change in a new version of the application, then it’s the time to update your unit test classes.
- Fourth reason: Codes are modularized.
It’s always good to modularize the codes to have many modules. It makes the development more flexible and makes it easier to change or add more features. It also helps us to reduce the duplicated codes in an application by reuse the same module instead of rewriting or copying it.
It’s a fact. To make an application testable, we are forced to organize it into as many modules as possible.
- Fifth reason: Reduce project costs (??)
It’s may not true for very small projects and when they don’t require maintenances. Some of you may not agree with this, you may believe that it costs more to write unit test than to not write it and it’s not worth to do it.
You are not wrong to say writing unit test costs. However, comparing to the overall cost of the project, including the bug fixings, the regression fixing, the time for tests and retests by testers, you will agree with me that writing unit test will save you a lot of times for later tasks. Further, with Continuous Integration tools (will be discussed in Part 10), unit test executed by your CI will even do the debug for you in another machine and it will save you a huge amount of time. Each commit to the repository will be checked by your CI.
Does high code coverage mean good quality?
Short answer: Yes.
In most cases, having Unit Testing with good coverage means your application is solid. However, it depends on how did you write your Tests. Usually, we write Test for happy cases, cases when application often work correctly. So, the good practice is to test as much corner case as possible.
And sometimes, we focus on having passed Test but we don’t focus on having the correct functionality. It may lead us to fix the unit test functions but not the implementation of the function being tested. It sounds strange, but it can happen.
How about the Cons?
The most drawback thing when you write unit test is time. Writing unit test takes a lot of time. Sometimes, your testing function can be longer and more complicated than the function to be tested. For a well-tested project, unit tests may cost you 25–30% of the development time.
My recommendation: take time to write unit tests for your application. If you don’t know how to write Unit test in iOS, take a look at the part 2 (link below). If you don’t have much time, write Unit test after having implemented the functions. If you still don’t have enough time to write them, ask your boss to give you more time :)
Part 2 is ready: https://medium.com/@haduyenhoa/unit-testing-in-ios-4e1f4f361efc . Let’s write the first Unit Test
You can find the source code of my examples here: https://bitbucket.org/haduyenhoa/testingfordummies
