Single responsibility. Separation of concerns. Code isolation. Data encapsulation.

These concepts are so universal. They are easy to accept and take for granted. But do you actually know what they mean? Can you explain them?

I’ll attempt to crystalize these buzzwords/theories/principles by taking a different angle.

There are two types of isolations.

1. Isolating components using protocols to declare inputs and outputs, and expose only external behaviors.
2. Isolating features using structs to encapsulate data in separate requests, responses, and view models.

Let’s explore each to understand how clean architecture can facilitate unit testing.

Continue reading →

The following story is horrifying, yet very familiar to any professional developer.

---

Chris the Client: How’s the app coming along? Are we ready to release it?

Dave the Developer: Great! All the features are working perfectly. And I’ve designed these classes to be small and reusable. It’ll be easy to maintain going forward.

Chris the Client: That’s fantastic! Let’s release this version 1 to the App Store.

Dave the Developer: Awesome!

---

Chris the Client: We’ve got some initial feedback from our users. And we want to add this new feature, and change this to that. How long will it take?

Dave the Developer: Hmm… If we’re going to do that, I’ll need to refactor this part of the app. It’ll take maybe a week.

Chris the Client: Why? I thought you said it would be easy to maintain.

Dave the Developer: Yeah, but your proposed changes will dramatically alter the way how things are working now. It’s not that simple.

Chris the Client: Okay, do whatever it takes. We want to get this out the door as soon as possible.

Dave the Developer: I’ll do my best.

---

Chris the Client: Some of our users are seeing crashes when they do this. Can you fix it?

Dave the Developer: Let me take a look… Ah, I found where the problem is. It’ll take a couple days to look into fixing it.

Chris the Client: Thanks.

Dave the Developer: This bug is really tricky. But it has been fixed. And I’ve released 1.1 to the App Store.

---

Chris the Client: Our users are still seeing crashes when they do this. I thought you said it was fixed!?

Dave the Developer: Yes, it was fixed. I’m not sure why it’s still happening. I can take a look.

Chris the Client: Yes, please do.

Continue reading →

This is part 2 of this terminology series:

• Terminology Part 1: Clean Swift Architecture
• Terminology Part 2: Unit Testing and TDD (this post)

This method is difficult to test.

How do I mock this class? With a stub or mock?

Should I test private methods?

Testing in the iOS world has been gaining more attention for the last several years. However, it is still in the minority. There’re still many who are just getting their feet wet. If you’re also wondering about these questions, I’ll demystify these vocabularies for you, and give you an overview of what unit testing is, its process, and practice.

Continue reading →

This is part 1 of this terminology series:

• Terminology Part 1: Clean Swift Architecture (this post)
• Terminology Part 2: Unit Testing and TDD

What should I name this class, struct, and protocol?

What is the difference between worker, service, and manager?

How should I name this function, method, and parameters?

These questions frequently come up in my mentorship program, especially when you just get started. People coming from other architectures may even get confused or overwhelmed with a bunch of new terms. You may be able to guess 80% of what these mean correctly. But having a shared vocabulary is important to communicate ideas to other developers effectively. You don’t want to waste 30 minutes to just get on the same page on the terminology.

So, let’s clarify the terms used in the Clean Swift Architecture.

Continue reading →

Unit testing is super useful, because it boosts your confidence to know that you aren’t breaking existing features while making changes to your app. However, they are notoriously slow to run, especially in Xcode. It needs to launch the simulator, install your app, launch your app, and loads the UI. If it takes too long to see pass or failure, it makes you not want to run them.

Fast feedback in unit testing is what makes it effective.

If you have two seconds to spare, I’m going to show you a quick tip from my book Effective Unit Testing to make all unit tests in your app run faster for the life of your project.

A quick tip to make your unit tests run much faster

When you generate a new project in Xcode, there are two boxes that are checked by default to generate both unit tests and UI tests. UI testing takes a considerable amount of time to run. When you hit ⌘U, it’ll run ALL tests. This can be very slow. When you’re looking for your unit tests to give you fast feedback, you don’t really want to run the UI tests.

There is a super easy way to disable UI tests. Just follow these simple steps. It literally takes two seconds to do.

Continue reading →