I believe that what makes us good programmers is a desire to master and improve the toolset we all have. With this in mind, one shiny morning at BlaBlaCar’s office in Warsaw I stopped for a while to look at how I can squeeze more from the old good XCTestExpectation. In this article I will show you a few juicy 🍹 things we now use to write our unit tests more efficiently.
These 4 tips can be applied to testing asynchronous code. I’m going to illustrate my thoughts with practical examples from different domains.
Tip 1: Fulfill one expectation multiple times
List of toggle switches is widely present in mobile world. I find it in “setting” screens of most apps that I use. For me, this simple act of switching things on and off plus saving it somewhere hides interesting complexity that I’m going to reveal.
In this article I will build “toggles list” screen with RxSwift. I’m going to use technique introduced in my previous article about Autocomplete. We will create Toggle component — a black-box with inputs and outputs to plug. After this reading you’ll be able to use it in your project to build your own toggling experience.
Toggle
…
Reactive programming gives a great opportunity for code reuse. The more time I spend using RxSwift the more intuitive it is to me to encapsulate some behaviors in components which can be used in different flows.
I call them “Rx Components” which is neither revolutionary nor astonishing. Just a way of dividing and conquering the Rx codebase. If you want to read another dude’s ideas regarding Rx world, stay with me — we’re going to build Autocomplete feature.
The Concept of Rx Component
What I call “Rx Component” is just a concept. No protocol to conform and nothing to subclass. This is the generic illustration:
Maciek Grzybowski
Software Engineer ⚡️
