Meet Cypress: Another Open Source Star that Makes Projects Shine

*Image source: https://docs.cypress.io/guides/overview/why-cypress

After more than ten years working on custom software projects, themes tend to emerge in how projects run. One prominent theme has to do with testing code, and how much people don’t like accommodating it. 

It’s not a very glamorous step, and even engineers at famous companies would rather write new code and try new experiments than check to see if their existing code passes tests. It’s also not surprising, then, that clients tend to fall into two distinct camps. 

The first is to skip or skimp on testing, especially in the front end. The reasoning make sense: the project is moving fast and the UI changes frequently. Better to just test later. (And then later keeps being… later.) 

The second is to go all in on testing: doing end-to-end testing on every feature, under every imagined use case, on every update. 

Somewhere in the middle is testing along the way as part of ensuring acceptance criteria are met, and that future updates or continued work don’t create new bugs in code that worked fine before. 

At The SilverLogic we’ve found a way to steer projects toward good testing coverage – and away from skimping – even in fast-paced projects with changing UIs, using Cypress.

What’s so great about Cypress?  

The two biggest reasons why we use Cypress are that it’s open source and it automates testing. 

We talk about the benefits of open source in another post. But this is a huge plus for us with Cypress, as advocates of open source software generally. 

Regarding automating testing, this is the secret to steering projects toward a middle ground while ensuring the code is as high quality as possible. Cypress allows our developers to: 

• Easily set up, configure, and write tests – which will from then on run automatically
• Efficiently test UI and performance in different browsers and device models  
• Receive visual outputs from testing to problem solve more quickly  
• Simulate user testing flows, not just individual functionalities 

How does this help your project – and your business? 

When your software development team includes testing in the plans early on, it is naturally easier to integrate testing steps into the workflow and spend less time – and therefore money – on it. Think of it like using the preventative healthcare screenings in your health insurance plan. It’s a lot cheaper, and easier to deal with, the results of tests that are done before there’s a sign of a problem. The plans that come with preventative screening included may be slightly more expensive, but overall, it is far cheaper when you consider the costs of disaster, in health or in your software project. 

Making the choice to include more comprehensive testing up front in your project has knock-on effects for your business: a more secure software project means less incidents, less down time, and less bugs, all reasons customers might lose trust and interest in your brand. 

What happens if you end up skimping on testing anyway? 

Unlike the health insurance scenario above, where you might not end up with a serious health issue regardless of doing preventative screenings, with software, you are quite likely to encounter a serious issue if you skimp on testing – and it’ll cost you more. 

For example, one team here at The SilverLogic did a project where it was decided to wait on doing front end testing specifically until the app met a certain user count and level of stability. The idea was to avoid the expenses that come with rework. (Aside: In the meantime, at The SilverLogic we still test, but do it manually, and on the primary user flows.) 

Then the project was presented at a conference. It turned out that what was considered a small edge case (a scenario for using the software that is much less likely – at the edge) was actually a big, main use case (scenario that is the main reason to use the software). And with several ways a user could execute it. 

The feedback started coming in, and the team needed to move fast to meet the demand for response. The manual tests take time and people have other responsibilities; testing couldn’t just run in the background. It was painfully clear that at least some Cypress tests would have been appropriate, in order to isolate what stayed the same and focus manual testing on what was changing. 

What seems cheap can actually be more expensive

As in health insurance, so too in software: sometimes making decisions based on what is cheaper will come back to be much more expensive in the end. And also as in health insurance, it can be a bit of a gamble to forego screening or testing. With tools like Cypress, especially when implemented at the very beginning, you don’t need to gamble tomorrow for the sake of today’s budget. If you have questions about testing or how we implement Cypress in projects, please get in touch!