Have you ever needed to test something that throws a fatalError?

Here is a quick tip to help you do that.

The Problem

Well there is a very simple hack to change this.

The Solution

The Test

When implementing a form with MVVM in SwiftUI, we end up having to deal with a lot of boilerplate code for our bindings.

Personally, I've been adopting TCA for my personal projects and as my main approach to SwiftUI views, but at work, there are some flows that the team decided to use MVVM. Being that, you can simplify things and avoid some boilerplate. To tackle this problem, I’ve come up with a solution inspired on a series from PointFree.co.

Simple / Common Form

Mockar valores para um teste pode ser algo bastante lento e moroso. E às vezes acabamos produzindo um teste verboso e de baixa legibilidade, que é ainda mais difícil de entender por causa da quantidade de configurações necessárias para a criação dos objetos do cenário.

Para melhorar esse tipo de situações e evitar estes problemas, pode-se utilizar uma técnica bastante simples: a implementação de Fixtures.

Fixtures são basicamente, inicializadores customizados para simplificar a construção de objetos nos nossos testes.

Estudo de caso e Exemplos

A generic approach to collect values when testing values in combine.


When testing something in Combine it's very common to end up having to collect values in order to validate scenarios like a state change, for example.
We could simply subscribe (i.e call sink) to a publisher inside the test and validate that, but it's possible to avoid all that boilerplate code with a simple implementation.

If you are new to Combine, here are some good references to give you a good start:

Case Study Scenario

For our examples, let's assume the code below. Which is a very simple…


Mocking values for a test can be a very demanding and sluggish.
And sometimes we end up with a big test code with bad readability, that is even harder to understand because of the amount of setup needed for our mock objects.
To improve this kind of situations and avoid these problems, we can rely on very a very simple technique: the implementation of Fixtures. They are basically custom initializers to simplify the construction of objects needed for our tests.

Case Study and Examples

Implementing Use Cases in Swift

What is a Use Case?

Source: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

By Uncle Bob's definition, a Use Case is basically an Interactor, which is responsible for encapsulating our Business Logic, and should have a well defined intention. But in the real world, it's very common to end up with bloated Interactors, in architectures like VIP/Clean and Viper, for example.

To avoid that kind of problems and really use interactors as a layer for logic integration, we can look back at the Command Pattern and think of a use-case a single command or logic operation.

With that in mind, our UseCase will represent a single operation, with…


It's very common to end up having to leave some change to your future self, when deadlines are tight and we end up creating technical debits.
To make it easier for us to decide which change needs to be applied right away, my team and I decided to create a tagging system for that.



Means that something can be changed, but it’s not that crucial to do it right away.


Means that an improvement can be made, and we strongly suggest it, but if it’s justified and not implemented, the PR will still be approved.


Means that something needs to…

Save time automating part of your code reviews

What is Danger?

Danger is an automation tool, that runs on your CI and checks for pre-defined code conventions, like: linting, formatting, and so on.


This article does not intend to teach you how to integrate Danger in your CI, but rather present some possible uses and pre-defined snippets for Danger Ruby.

For more informations about its configuration process, reffer to the Getting Set Up guide, from Danger's documentation.

Possible uses

It can be very useful to automate validations like:

  • Code formatting and Linting
  • Warning for changes on a specific file
  • Checking for the presence of Unit…

Creating buttons is something we have to do very often…
What if you could simplify their configuration with a simple extension?

The Apple Way

To configure a button action we normally set it’s action from a selector and that’s it…

The Extension

A button have an action, which is defined as a selector.
A selector is, in a simplified explanation, just the name of some method that needs to conform to @objc and dispatches an action.

This way we can define an action as:


With this extension, configuring a button action now becomes this:

Speed up your development process and create cleaner code.

This time we will present some extensions that can simplify and speed up your development process. The code presented here can be used by copying and pasting it to your project.

1. NSError

Every time I have to create a simple NSError instance with just a description. I end up having to make a web search to remember which one is the key related to Localized Description.
After doing that lots of times, I've started using the extension below.

2. NSObject+ClassName

Aren't you tired of having to set the names of your cells, xibs and such with a raw string?

Eduardo Sanches Bocato

iOS Engineer, AI enthusiast, Crossfit/Gymnastics. Currently working as iOS Lead @WarrenBrasil.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store