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.
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.
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:
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.
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
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.
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
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.
It can be very useful to automate validations like:
Creating buttons is something we have to do very often…
What if you could simplify their configuration with a simple extension?
To configure a button action we normally set it’s action from a selector and that’s it…
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.
With this extension, configuring a button action now becomes this:
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.
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.
Aren't you tired of having to set the names of your cells, xibs and such with a raw string?
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.
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…
In case you need…
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?"
iOS Engineer, AI enthusiast, Crossfit/Gymnastics. Currently working as iOS Engineer @WarrenBrasil.