Let's try to test the behavior of the button component based on the passed parameters.
Understanding tests for React components
Firstly, we need to create
Buttoncomponent which will be fully customizable. We'll use approach called
types first- first interfaces, implementation later:
consts.tsfile we'll store constants. We want to limit options for better
Take a look at implementation for
You can choose
sizeand other aspects. This is how it looks like in
We need to think before creating the tests. What should be tested? Component takes several props and creates
classNamefor styling purposes. In addition, there are other
nativebutton properties injected which comes from
ButtonPropsinterface. So it's good to test:
So let's write first test - the easiest one:
getByTextallows you to get the HTML node by text. This method is using
expectinside. If the element is not found - the test will not pass (a slight shortening).
In React we use
react-testing-libraryon daily basis. First one is responsible for faking
DOMbehavior and test execution.
The second one is simple lib that allows you to write tests from
user perspective. Instead of searching by
classNamewe should select by text, role or something what is visible for user (placeholder, input value).
If you are interested check
RTLdocumentation for more info.
Adding missing tests
Let's add tests for:
First test checks
implementation details. If we change order of classes or we'll add new class - this test will fail. Failure in this case doesn't mean bug. It means the order of classes changed. This is called
false negativeand should be avoided if possible.
In second we passed
roleproperty to check native button properties injection.
Dealing with ugly tests
How can I fix previous test? You can cover this case with other type of test -
visual test(we'll explain it in another lesson).
Another option is to leave it as it is. In this case you need to remember that it may fail and it's
fragileto change in implementation.
Sometimes you need to test implementation, we'll cover it in next lessons.
Unfortunately, nothing is perfect. Such a test has value, but it carries risks. It's worth to highlight it somehow, so developers won't be surprised that the test fails after class names order change. In such situations I always add
[FRAGILE]before the test description, so later it's easy to find these and replace them. After change our fragile test description will be:
it('[FRAGILE] assigns class names by properties')
As a developer you decide which suites are valuable for you. Tests should save you from bugs and regression instead of being perfect and pretty. It's is not a fashion revue.
You can find full implementation on this
As you saw - React components testing can be tricky. Some areas are hard to cover with qualitative
unit tests. These areas requires other type of tests or practices which we'll cover in next lessons.
If you enjoyed it, be sure to visit us onLinkedinwhere we regularly upload content from programming.
- 1. Basics
Grouping the tests
The usage of describe and it
The best practices for naming tests
Types of tests
- 2. Mastering unit testing