How Medinas started deploying every day by using TestCafe
Solving a $765 billion problem
Medinas creates tools to help hospitals manage asset disposition. Hospitals utilize over 9,000 different types of medical equipment — everything ranging from defibrillators to MRI machines. When hospitals remove any of that equipment from service, they often don’t have a good plan for what to do with it, and the equipment ends up gathering dust and taking up space in hospital store-rooms.
Hand-testing slowed down deployment
Before each deploy, I would hand-test all of the primary user flows through our app (creating listings, updating listings, making offers on listings, etc). This started to take hours to complete, which meant we couldn’t ship as fast. I’ve had prior experience with mature applications using Cypress and Nightwatch. Both had become tangles of configuration files and outdated underlying frameworks that, on upgrading, would break a lot of our tests. I didn’t want to fall into that same pattern again, and stumbled on TestCafe. They made the claim that they were configuration free, so I gave them a try.
Why TestCafe
We’re a startup – and we needed to fix the fact that we were testing by hand and taking hours before deployment. Time is always against you. I didn’t want something that was infinitely configurable. I wanted something that was easy to use out of the box, opinionated, and had meaningful APIs for configuration if needed later. All of these were true with TestCafe.
Saving hours per week
We couldn’t deploy very quickly because I was testing by hand and needed a solid e2e framework that could get me up and running quickly. Now that we have e2e testing in place with TestCafe, I’m able to push code to our CI pipeline and have the TestCafe tests run headlessly every time – saving me hours per week in testing and preventing defects from shipping. Regardless of engineering team size, our e2e tests (powered by TestCafe) now reduce the number of defects shipped, and are able to run in the background almost immediately after a pull request is created. It also creates a contract around the intent of what was developed in the platform. For example, if we make a decision about how a feature works, and that feature isn’t updated or touched for 6 months, we’ll often forget the context and nuance behind how it works (regardless of how much documentation we create around the feature). It’s very easy to make a change without realizing the impact of prior-made decisions. Our testing layer helps prevent us from breaking those features. One of the best ways to prove a product is worth the time is based on how quickly you can see it working in your own project. Take 60 minutes, install it, aim it at your web project, and have it click around and run an assertion. You’ll see how easy it is to build with.
Results
- Saved hours in testing and preventing defects from shipping
- Reduced the number of defects shipped
- Prevented breaking features once changes were introduced
- Sped up deployment from once a week to daily