Effective Unit Testing

Unit testing is a double-edged sword.

If done wrong, unit testing feels like extra baggage. You’re essentially writing and maintaining your app twice. Making changes in one breaks the other. You start to wonder what is the point of writing all these tests that break all the time. It slows you down. It doesn’t add any value. And you can’t justify the extra time and cost to your clients or managers.

But at the same time, you hear all the good things about unit testing and TDD. All the experienced programmers have been doing it for years. Don’t you want to know how they do it?

If done right, unit testing gives you the confidence to add new features and refactor while knowing your app always works. It prevents you from breaking existing features and introducing regression. Unit tests should be easy to write, read, and maintain. They save you time and speed up development.

Most of all, unit testing makes it more enjoyable to write your app code and test code. You’ll spend your time thinking about interesting problems, instead of cursing at someone else’s code or feeling ashamed about your old code.

Do you want to learn how to write effective unit tests that’s done right?

Have you tried to change one line of code and 16 tests fail?

When they try their hands at unit testing for the first time, many developers suffer from this fragile test symptom. You write all these test methods, polish them, refactor them. And then there is a change in the requirements. You change one line of code to see what happens. Voila! 16 tests scream FAILURE at you.

You are frozen. You don’t know what to do. Do you really have to fix 16 tests before you can add that new feature? You’ve just broken the app and the tests. Whenever you change the app, the tests break. Whenever you change the tests, the app breaks. It feels like there are two apps to maintain. The tests are so fragile, so you revert the change and proclaim: ”I don’t wanna touch this code!”

Even more mysterious. This one test passes some time, but fails other times. But the code is the same! Is there a race condition? Is it a framework bug? Is it a build issue? Maybe try a clean and rebuild? Let’s try it on a real device. Maybe it’s just the simulator. Oh wait, I should have my eyes checked out by a doctor. Eventually, you run out of logical reasons. It makes you want to throw your hands up and give up unit testing altogether.

What if I assure you that your eyes are okay? What if this fragile tests problem can be solved by simply learning how to write testable code? You can completely turn it around. Your unit tests will not be a hindrance to maintaining your app. Rather, they’ll help maintain your app.

Imagine you can isolate your code such that writing unit tests becomes trivial, even boring

After you learn how to architect your app into small testable components, the inputs and outputs are obvious. Writing unit tests then becomes trivial. You simply perform the following steps:

Given: Provide the inputs
When: Execute a method on the test subject
Then: Verify the outputs

If you change the method implementation such that the outputs are different, only 1 test will fail instead of 16. And it comes as no surprise. Your test methods are testing one thing at a time, with one set of inputs, and one set of expected outputs. Therefore, you know exactly which method will fail. Everything is predictable.

Of course there are more details. How do you cover all the edge cases in the inputs? What if you app works with other external dependencies such as networking? When and how should you mock and stub? You’re going to dive into these details throughout this book.

How many tests should you have? Do you need to test every single method for every single class? Even private methods?

Have you ever felt that a test is too trivial? Or when a method seems like there should be 20 tests written to fully test its behaviors? You’ve also undoubtedly heard of the debate about whether you should test private methods.

When you properly build your app with testable components and interfaces, you only need to follow the Given-When-Then steps for each test method. Rinse and repeat for all methods defined for the component interfaces. And you’re done.

Let me set this straight once and for all. You do not need to test private methods. Your tests care only about the inputs and outputs. If the outputs match your expectations, the test succeeds. If not, it fails. If you were to test every private method, your tests will be coupled to your implementation which leads to fragile tests. You don’t test private methods directly. Instead, you test methods that depend on the private methods. Private methods are allowed to change. This is called refactoring. And there are two reasons to refactor: generalize the code to work for more edge cases, or optimize performance.

After you grasp the components and interfaces of your app, you can then properly evaluate the ROI of your tests. Does this test provide enough values to the overall correctness? Does this test ensure some critical behavior that is essential to the user experience? You’ll also be able to devise a complete set of inputs to fully cover all the edge cases such that no important behavior is left untested.

Moreover, you can refactor your unit tests too. Long methods are hard to read and understand, regardless if it’s a method in your app or your tests. Often, the bulk of a test method is in all the mocking and stubbing, and also preparing the input data. You’ll learn how to refactor your unit tests so that mocks, stubs, and seed data can be created once and reused for your entire test suite. This is an important step.

You will learn all the in’s and out’s of unit testing

Effective Unit Testing walks you through how to write unit tests for the CleanStore sample app in every single details. You’ll learn the why, what, and how, so that you’ll be able to apply everything you learn to your own apps.

Imagine you know exactly what and how to write your unit tests:

How to break down your app into multiple testable components
Establish clear boundaries between components so you’ll write only those tests that are necessary
Understand what code dependence and data dependence are and how to use them to write robust unit tests
Clearly identify the test subject, inputs, and outputs to make testing straight forward
Use dependency injection to mock external dependencies to keep your tests focused
Understand the whole unit test setup process – more than just setUp() and tearDown()
Follow the same Given-When-Then steps so all your tests are consistent, easy to read and understand
Learn when and how to write different kinds of test doubles in just a few lines of code without using any framework
Cover all your edge cases to fully cover all desired behaviors
Test asynchronous operations such as networking, database, and API
Automate the generation of your unit test files with the Clean Swift templates so you can start writing tests right away
Organize your test files and methods so they are easy to find in both Xcode and Finder
Write tests that are fast so you’ll actually run them and run them often to receive immediate feedback
Use TDD to write testable code that drives feature development
Never have to worry about introducing regression to your app when making changes
Have total confidence that your change will not break existing features
Write non-fragile unit tests so they become valuable assets, not liabilities
When your tests pass, your app works, so you can release to the App Store

When you buy Effective Unit Testing, you’ll get instant access to:

A 177-page ebook in PDF format (expanding after the early bird launch)
A super handy cheat sheet to remind and reinforce the steps to always keep you on track when writing unit tests
A list of all pro tips from the book for you to easily refer so you can avoid the common pitfalls when you have doubts
BONUS You also get one month of 24/7 access to my premium mentorship program (a $149 value). You’ll participate in our private Slack team to get help when you’re stuck. You’ll get instant access to screencast tutorials in our private Wistia group. There are currently two screencast series on the following topics:
- How to convert your existing project to Clean Swift (over 3.5 hours)
- How to add unit tests to your existing project (over 1.5 hours and expanding)

You can get all these for just $99.

With Effective Unit Testing, you’ll have everything you need to start writing unit tests today. My goal is to turn your doubts upside down. You will be able to find joy in writing your unit tests. When you leave work, you can finally free up your mind for your family and friends. You don’t have to think about code at night when you have unit tests that cover everything about your app.

Buy Effective Unit Testing Now

I use Gumroad for payment and fulfillment. It’s the preferred way of making purchases on this site, because it can instantly deliver the contents to you. However, Gumroad doesn’t support certain countries. If that’s the case for you, you can use this special link to pay. When I see your sales come through in my inbox, I will deliver the book to you.

There is a special $30 bundle discount available if you buy both The Clean Swift Handbook and Effective Unit Testing together. You’ll pay only $168 ~~$198~~. It also includes one month access to the mentorship program. You can buy this two-book bundle now (preferred Gumroad link). If Gumroad doesn’t support your country, use this special bundle link.

What will be covered

Here is the table of content for the book:

The Basic Building Blocks
Black Box Testing
Architecture Before Testing
The Key to Writing Non-Fragile Tests
Unit Testing at the Boundaries
The Structure of an Unit Test File
The 3 Steps of an Unit Test
Test Doubles
Organization of Test Files
Generating Test Files Using the Clean Swift Templates
Testing the ListOrders Scene
Testing the CreateOrder Scene
Test Driven Development
TDD the ShowOrder Scene
Testing Asynchronous Operations
Refactoring with Confidence

The How to convert your existing project to Clean Swift screencast covers the following topics:

Dissecting the app’s existing features
Create a new scene and adjust project settings & storyboard
Create a new use case to go through the VIP cycle, plus a little refactoring
Move delegate out of the view controller to the interactor
Format error messages in the presenter
Break up complex logic into multiple smaller use cases
More use case and VIP cycle goodness to finish up scene
Prepare data for passing to next scene
Routing and passing data to next scene
Review what we did and wrap up

The How to add unit tests to your existing project covers the following topics:

Set up new test target – Build and run
What is unit testing and seed data for tests
Create new test files
Testing the Placemark Interactor
Test Doubles – dummy, stub, spy, mock, and fake
Testing the Placemark Presenter
View controller tests setup
Testing the Placemark view controller – Part 1 View lifecycle
Testing the Placemark view controller – Part 2 Stub out UITableView
Testing the Placemark view controller – Part 3 Isolate your unit
Testing the Placemark view controller – Part 4 Cells and labels

More about the mentorship program

Watch the videos to learn how to clean up your existing projects. Take advantage of the mentorship bonus now to guarantee your success. Ask questions and have your code review by me.

This is not just yet another ebook that you buy and forget. I design this package so that I’ll be there to personally interact with you when you need it. When you ask me a question in Slack, don’t expect a short answer. I’ve been known to provide super long and detailed answers to walk you through my entire thought process. I’ve even put together some sample projects to demonstrate how to make Clean Swift work with the tab bar controller, notifications, and container views.

This isn’t some other Slack teams where you get a lot of noise but few substances. All discussions are specific and practical. They arise from real world projects that we, and you, are actively working on. You don’t need to worry about catching up to all the discussions in the many Slack channels. At the end of every month, I’ll provide a monthly roundup to all my subscribers on that month’s takeaways. You won’t miss a beat.

The mentorship program bonus you get will start on the date when you accept the invite, not on the purchase date. Many people are working on MVC projects at work but want to take advantage of this deal to learn Clean Swift a couple months away. So rest assured, you’ll be able to start the one month whenever you’re ready. So, if you’re interested, get it now and use it later. I’ll always do what makes the most sense for my customers.