React
Quality assurance engineers are the secret superpower of
web development. A good QA engineer and a strong QA
process can save development time, reduce issues in production
and have been known to save the reputation of entire development
teams... and the companies they work for!
QA engineers have a totally different mindset to developers:
developers naturally build against assumptions about how
something should work and can only test these assumptions.
QAs, on the other hand, challenge these assumptions, using every
trick they can think of to try to break the code in some way. This
ensures that your customers aren’t acting as your QAs, causing
you to lose money and good will in a very public manner.
A dedicated QA engineer will write an automated tests suite
that checks the expected functionality of the built application,
predominantly on a staging domain, in addition to end-to-end
tests that will check users can carry out goals that you expect
them to achieve.THE ROLE OF QUALITY
ASSURANCE ENGINEERS
IN-DEPTHAbove Testing your code before putting it in production means you can rest easy that no
nasty surprises will rear their ugly headsit already comes preconfigured with the testing
library. If you’re using Gatsby or a custom setup, there
might be some configuration you need to run through
before you start using the testing library.
To begin, let’s create a new app. If you have a recent
version of Node.js already, you can run the following
command without installing anything else globally:
npx create-react-app netmag-javascript-testing
Now open the folder in your code editor.
Create-react-app is great because you can run
yarn test and see that one test is already passing. This
command will also keep watching for file changes, so
you can see straight away whether or not the tests you
write are passing.
LET’S START WRITING SOME TESTS!
DECIDE WHAT TO TEST
Imagine we have a simple component, say a button
with some state. What are some of the things that
need testing in a component like this?
O The appearance of the component
We don’t want anything to change unexpectedly
after we’ve written our component. So we’re
going to write a snapshot test to capture how it
renders. Then, if anything changes, we will see
it quickly without a manual or visual test. This is
great for components that consist of many smaller
components: you can see quickly when (and where)
its appearance has been affected.
O The different branches that render
Because we could have two or more different
outputs, we need to test it’s rendering all of them
correctly, not just one of them. So we need to
simulate a click event and have another snapshot
test for the way it renders after this branch of code
has been run.
O That functions get called as expected
We want to ensure that the code we wrote to call
“We don’t want anything to
change after we’ve written
our component. So we write a
snapshot test to capture how
it renders. Then, if anything
changes, we will see it”