Image for post
Image for post

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

Agora imagine que o objeto User tem ainda mais propriedades, mas para nossos testes a única que importa é nickname.Você…


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

Image for post
Image for post

Introduction

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…


Image for post
Image for post

Introduction

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

Let’s suppose that the User struct has even more properties, but your tests are interested only in the nickname


Implementing Use Cases in Swift

What is a Use Case?

Image for post
Image for post
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…


Image for post
Image for post

Introduction

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.

Tags

[NICE TO HAVE]

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

[SUGGESTION]

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.

[CHANGE REQUEST]

Means that something needs to…


Save time automating part of your code reviews

Image for post
Image for post

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.

Disclaimer

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…


Image for post
Image for post

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 that, we can create our extension.

Usage

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


Speed up your development process and create cleaner code.

Image for post
Image for post

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?

One of…


Image for post
Image for post

This is part #3 of a series on tips and tricks to improve your Swift code.
You can check the other posts here and here.

9. Result type handling

Consider that you have the Networking implementation that returns the Result type with a closure, like defined below.

You can deal with the result of those calls with some very different approaches, let's exemplify some of them.

Handling with a switch

Using the get function

Supposing you don't want to handle errors and such, you could handle it like this:

If you want to deal with the error, it could be handled using a do-catch

Mapping the failure and success

In case you need…


Image for post
Image for post

Recently I was writing a Network layer and ended up creating NetworkError as I normally do: using an enum to specify the possible types of errors.

It was something like this:

There is no problem with this, but since I have to send some error logs through my logger module, I wanted a simple way to get all the information I needed without having to send the specific types to it.

I thought: "When I want more information about a system error, I normally try to cast it to NSError… What if I could that with my error too?"

Eduardo Sanches Bocato

iOS Engineer, AI enthusiast, Crossfit/Gymnastics. Currently working as iOS Engineer @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