🖼 Cover image by Marta XimenisCampins
Some context
During the beginning of the pandemic 🦠, a friend who works as a cook 👨🏼🍳 started to teach us some new recipes during weekly video calls 📲. I started this project to manage those cooking recipes and the photos of the resulting dishes 🍽.
I named it "Cooking with Amateurs" ("Cocinando con Amateurs" in Spanish). At the time I was already developing a Components Library 📚 named Chemistry-UI (I even wrote a previous post about it!).
I wanted this project to be scalable 💗, and a good showcase of best practices as I'm bored 🥱 of doing code tests for potential future employers and I wanted to have a decent portfolio 🖼.
So, I needed to develop a good test suite ✅ for this project (I even added a coverage script). For unit tests, it was clear to me that I wanted to use Jest and that I was going to focus on the "model" modules, where my main business logic ⚙ was gathered. But for Functional Tests, I needed something else 🤔.
About Functional Tests Tools
There are a lot of different tools 🛠. In addition to Cypress, I have worked in the past with Selenium too.
When choosing the right testing library for you ⚖, it's important to look for one that somehow "enforces" a good testing paradigm. I have been using Cypress 🌳 in many projects, professional and side projects. It always adapts wonderfully: its API is clear and there are some interesting community-developed plugins´💖.
Can't say I find Selenium so easy to use: in many projects I worked on in the past, app developers had to develop libraries 📚 on top of selenium in order to get a consistent platform that every user in the team could use without much effort 😅.
Who should develop these tests?
In big companies, there's usually an independent role 👩🏿💼 (QA Engineer, or Testing Engineer) in charge of developing this type of testing. I believe this is not the more optimal management: there're many benefits that you gain when App Developers 👩🏼💻 create functional tests too:
Functional tests, as unit tests in TDD, forces you to uncouple 🪓 your code to test it properly. For example, defining an API allows you to mock that API and show any data you want on the UI 🖥. Another case: calling an external module 📞 from inside the module you want to test. You'll find that you need to inject that dependency in a way you can mock it 🤥. This will also result in better quality app code 🌟.
If you write descriptively named tests 📄, you can mimic the actual requirements for that development! At some point, I worked on a project that used Selenium + Cucumber 🥒 + an abstraction layer that allowed anybody without technical knowledge to write tests as requirements ✍🏼 (for example: "User enters the page and completes the login").
You can randomize the characters and the lengths of the strings that your UI displays 💻. This is useful to check the responsiveness of that UI and allows frontend developers to be more aware of possible visual bugs 🐛.
Some last comments
Functional Tests have a lot of benefits, but you have to develop them in good measure ⚖. They are usually expensive to run 💰, so you don't really need to cover all your features. It's better to just cover the core features (for example, the login or the buying process) ✅.
If you want to test complex logic ⚙ or achieve a code coverage close to the 100%, you need to invest in unit tests, not functional ones.
So, what do you think? Have you tried Cypress already, do you love it 🤗?