Skip to content

About testing

As a developer, you want to ship bug-free code. Nothing is worse than finding out on Monday morning that your Friday changes broke the live application! The only way you can make sure your application works correctly is by testing it, so it’s vital that you learn how to test applications thoroughly.

A good testing approach speeds up development, improves code quality, and limits the bugs in your app. A poor testing approach cripples a project.

Developers make mistakes all the time

We can misunderstand requirements, miss semicolons, overlook edge case scenario or just forget about certain business requirements. Mistakes happen and it’s almost impossible to avoid bugs.

Some developers tend to skip testing and just throw the code “over the wall” to QA testers and just wait for issues to be reported. It takes a lot of time to go back and forth, deliver a feature, test, report a bug, fix it, test again, repeat.

Manual testing

Every employable developer tests code manually. It’s the next logical step after writing source code, like how the next step after chewing food is to swallow it.

Imagine you’re creating a sign-up form. When you finish writing the code, you don’t just close your text editor and tell your boss that you’ve finished the form. No, you’ll open the browser, fill out the form, and make sure it completes the sign-up process correctly. In other words, you’ll test the code manually.

Manual testing works great for small projects. If you have a TODO list app that you can check manually in two minutes, you don’t need automated tests. But when your app grows to a certain size, relying on manual testing becomes a burden.

Warning

Manually testing hundreds of features is difficult — it’s all too easy to lose concentration and forget to check something.

Automated testing

Automated testing is the process of using programs to check that your software works correctly. In other words, you write extra code to test your application code. After the test code is written, you can test your app as many times as you want with minimal effort.

You can use lots of different techniques to write automated tests. You can write programs to automate a browser, call functions in your source code directly, or compare screenshots of your rendered application. Each of the techniques has different benefits, but they all have something in common: they save you time over manual testing.

Code coverage

Code coverage is a measurement of how many lines in your codebase are run by your automated tests. Normally code coverage is measured as a percentage: 100% code coverage means every line of code runs during the execution of tests; 0% code coverage means that no lines are executed. It’s a fun measurement, but it can lead to some dire consequences.

You can write simple tests that cover your applications’ core features in a few hours. After you’ve written those tests, increasing your code coverage gets progressively more difficult.

Most of the time, 100% code coverage is not something to aim for. Sure, if you were working on a mission-critical payment app where bugs can cost millions, then 100% code coverage would benefit you.

Not only is it time-consuming to reach the fabled 100% code coverage, but even with 100% code coverage, tests do not always catch bugs. Sometimes you make the wrong assumptions. Maybe you’re testing code that calls an API, and you assume that the API never returns an error; when the API does return an error in production, your app will implode.

code coverage report example
Example of code coverage report.

Test-driven development

Test-driven development (TDD) is a workflow where you write a failing test before you write the source code. Before you write code in a component, you write a test to makes sure the component behaves correctly.

A popular TDD approach is red, green, refactor. Red, green, refactor is where you write a failing test (red), make the test pass (green), and then refactor the code to make it more readable.

Developing applications like this offers some benefits. First, you write source code only for the functionality that’s tested, which keeps the source code small. Second, it forces you to think about component design before you start writing code.

Some TDD advocates write all test code before the source code.

Steps for TTD:

  1. Decide the components you need.
  2. Write unit tests and source code for each component.
  3. Style the components.
  4. Add snapshot tests for the finished components.
  5. Test the code manually in the browser.
  6. Write an end-to-end test.