This is the third article in our series about essentials for developing R&D applications — the seemingly small things that are easy to overlook but make your project go much more smoothly. Be sure to check out our articles on documentation and repeatability.
Practically everyone seems to understand the need for testing your application before going live. So why is it so easy to take for granted, skip steps, or ignore completely?
Testing is something that everybody understands is important. Tests are how you raise confidence that it does what it does before you release it into the wild. It’s risk mitigation, and it elevates the confidence in your code base that your application is doing what it’s supposed to do. Many people skip this step because it’s extra code to write. It can be easy to miss the forest for the trees if you focus too much on getting features done with a checkbox mentality.
The way we see it, a feature that doesn’t have repeatable tests written around it is not a complete feature. You can end up with lots of bugs in production, which sets off the chain reaction of documenting the bugs, digging through code, trying to figure out what happened, reconstructing, and playing catch up.
This can all be avoided with the right testing process.
Avoiding the Disaster Scenarios
The easiest way to understand the benefits of testing is to picture what can happen if you skip over it. While we don’t necessarily want to paint a dreary picture, the fact is that skipping tests makes it more likely for some disastrous scenarios to take place:
- Introducing bugs into your code
- Breaking your layout
- Breaking key functionality
- Frustrating users
- Exposing a security weakness
- Causing a breach
- Leaking HIPAA-protected data
- Loss of productivity and/or revenue
No one wants that. But these are all realistic consequences that have happened.
It can be harmful, embarrassing or even illegal to release an application into production when it doesn’t function in the way that you expect. You’re better off taking testing seriously upfront and building it into your project timelines.
If We Know Testing is Important, Why Don’t We Do It More Often?
Sometimes developers don’t know testing tools very well because they’re focused on how to hone their skills for writing code. Testing is a totally different skill set, and it requires a different set of technologies. Sometimes they’re uncomfortable learning about testing because it feels like a distraction from their core job. And sometimes they just want to get the thing done and move on to the next thing.
But if they care about the product that they’re developing, they’ll need to learn how to effectively set up tests and automation pipelines (more on that in a minute). Sometimes it’s simply a matter of recognizing that if a human tried to handle all of the testing manually, they basically wouldn’t get it all done, and it would be very inefficient.
What types of tests should we be conducting?
The specifics of testing cover a range of topics including bugs and functionality issues, but fundamentally you are checking whether your code works. Does it actually do what it’s supposed to do?
- Functionality tests – Basic tests that things work the way they’re supposed to work.
- Security scans. There’s lots of tools out there that can perform security reviews of code and can produce output that you can integrate into an automated pipeline. You’d say, “Hey, if this finds any critical findings, don’t release it. We have to remediate those first.” It’s healthy to view security scans as a form of testing, in this case testing whether your code is secure.
- Visual regression testing can catch when items aren’t displaying properly on the page. CSS updates and other adjustments to the look and feel can quickly become a muddled mess. Maybe you updated the style of an item on one page but didn’t realize that it applied to other pages until it busted your navigation. Visual regression tests help prevent unintentional changes to your application’s visual elements.
- Performance testing. Does your site load fast enough, and what happens if it doesn’t? Integrated performance tests can gauge how fast something loads and if it’s benchmarking above your target, don’t release it.
Why does it matter? Time is money:
10 years ago, Amazon found that every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%. A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition.
A 2017 Akamai study shows that every 100-millisecond delay in website load time can hurt conversion rates by 7% – that is a significant drop in sales – 6% – from the time when Amazon first talked about latency in seconds and milliseconds. (Yoav Einav, Gigaspace)
Automating is key
It’s vital to build testing into your development process, but it’s just as important to do so without taking up too much of your team’s time. The best practice for tests is to automate them. Thankfully, there are a lot of tools to help.
Automation happens through a pipeline – an infrastructure and process for rapidly testing code. An automation pipeline for testing helps you avoid deploying bad code at a rate that basically isn’t possible otherwise. The challenge with a pipeline is standing it up in the first place and getting the infrastructure in place. Once you have a pipeline set up, you can integrate it into each project.
A pipeline simplifies the process to identify bugs, fix failures, and rewrite code, all without having to do so manually. When you fold your test suite into your pipeline, you can run one command to execute all of your tests. You can also automate notifications when it discovers bugs. There’s also an economy of scale that comes by sticking with the same development stack. At some point, you’ll have less work to set up new environments. As you add new programs and versions, it’s fairly easy to integrate another test suite.
Simplifying your testing process helps your application to run more smoothly and avoid nightmare scenarios. And that gets you one step closer to deploying code that’s successful, productive, and repeatable.
Justin Bantuelle balances the responsibilities of both the Chief Operating Officer and the Web Technology Director after having worked with Health Connective for more than a dozen years. Justin regularly leads the cross-disciplinary teams in building out and updating applications for Fortune 500 companies.
Justin keeps his technical abilities sharp by contributing to an eclectic mix of open-source and personal projects on Github.
Jared Johnson
Jared builds innovative healthcare brands through digital strategy and engaging content that turns heads. He is a keynote speaker, prolific content creator, host of the Healthcare Rap podcast and author of Connect the Docs: Put Digital Health Into Practice.