Cypress | Automation Testing | Quality Assurance

My first code review… how did it go?

What is a code review?

For all the readers who are not familiar with code review, I have found a great definition sourced from GitLab

Code reviews act as quality assurance of the code base. Software developers should be encouraged to have their code reviewed as soon as they’ve completed coding to get a second opinion on the solution and implementation. The reviewer can also act as a second step in identifying bugs, logic problems, or uncovered edge cases. Reviewers can be from any team or group as long as they’re a domain expert.

What do I do at my work?

First things first. Automating tasks always fascinated me. Why do something repetitively when a robot could do it for you? Didn’t we all dream of that at one point?

Such approach + passion for quality = Test Automation! 

Recently, I was super lucky to join the automation team at Madison Logic. I found out the engineers here are using Cypress.io and it made me feel super happy, because I previously read about it, and I was curious about what it can do!

Even though we have access to great sources for Linkedin Learning, the Cypress course was not there. I quickly turned to udemy and bought the highest-rated Cypress course without blinking an eye.

Was it worth it? 100%, I can surely recommend the one I went through. It gave me a nice base of cypress’ abilities, learned the good practices and I have even scratched the surface of more advanced concepts, such as API testing, CLI, NPM scripts and cross-browser testing.

With that knowledge at hand, I was ready to start writing simple tests!

What did the code review teach me?

It was a real game changer, I can assure all of you to always ask for feedback on your code.
Everything came in the form of a highly detailed file, which pointed to every single element, that could have been written better/smarter.

But what exactly did I learn?

  • Locators — those can be your friend if you know how which ones to take, and what anti-patterns to avoid. For example, for locators that could be similar on different tested pages within one application, always try to identify a unique parent element
  • Remove unnecessary code — luckily modern integrated development environment(IDE) will let you know which parts were not used. Make sure you remove that part, especially the importing bits 😅
  • D.R.Y — This rule is a general good practice for all the coding. It stands for “Don’t repeat yourself”. Anything that has been used more than twice could potentially be refactored.
  • Guarding — Extremely important bit! I might try to explain it in more detail in another article, but in general: that’s another assertion that will “buy us some time” to make sure all the elements are loaded properly.
  • Proper Naming — There are loads of stakeholders around the app, make sure that non-technical ones understand what your tests are doing and how elements are connected within the process.
  • Enhanced my TypeScript knowledge — even though I already understand a few TypeScript concepts, it’s always good to play around with them in practice, as we all know — practice makes perfect!

This code review session was an eye-opener, especially since I was given time to sit and re-write my previous code. From now on, we only write high-quality, robust and reusable tests, right? 🎓

Thanks for reading, and let me know about your experience with code reviews!

--

--

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
Maciej Rojek

Maciej Rojek

Automation test engineer @ Madison Logic | Cryptocurrencies enthusiast | Meme Lord 🧙