Useful test automation strategies you should know now

In modern web applications, test automation is crucial for quality and maintainability, but many developers struggle to write test code because they lack experience writing test code.
This book is aimed at front-end developers who are writing test code for the first time, and explains not only the basic test code writing method, but also the situation-specific test code writing method and how to use various tools, with abundant examples.
In particular, it includes examples created with TypeScript and Next.js, allowing you to acquire the latest practical knowledge and know-how.
The Korean version has been further improved by adding UI component testing and E2E testing in GitHub Actions as appendices.

Code modifications aren't just necessary when developing new features.
Modern front-end development relies on numerous libraries, so updating libraries also requires modifying your code.
Of course, if you use Dependabot, it will automatically check for vulnerabilities that may occur when dependent libraries are updated and create a pull request.
However, you should not assume that Defenderbot will filter out all vulnerabilities.
If you have written test code, you should establish a rule such as 'minor updates can be merged if they pass the tests'.

--- p.6

Refactoring can be scary when your released project doesn't have any test code.
At this time, you should first organize the released features into a list.
Once you've sorted it out, write regression tests to verify that no defects occur before or after the change.
With regression tests written, you can confidently start refactoring.

--- p.23

The more similar a test is to the actual execution environment, the more reproducible it is.
However, as reproducibility increases, execution time may become too long or environment setup may become difficult.
A typical case is when you need to handle data obtained from a web API, and when you obtain data from the web API, it sometimes fails due to reasons such as a network error.
When using a web API, you need to test not only the "success case" but also the "failure case."
/ If successful, you can test it if you can connect the actual web API server to the test environment.
It is not right to add code to the web API server to test for failure cases.
Moreover, it is impossible to add a test implementation to the web API of an external service in the first place.

--- p.53

Coverage is a quantitative indicator that can be objectively measured.
Depending on the project, it is also used as a quality standard that must be met.
For example, it can be used to create a pipeline such as 'If branch coverage is not greater than 80%, it does not pass CI'.
(...) Coverage is used as a trigger to review whether tests should be added to a specific file.
It's also useful for finding duplicate code that passed ESLint but remains.
We recommend consulting coverage reports to determine if there are any areas that were not sufficiently tested before release.

--- p.132

Storybook's test runner converts stories into executable tests.
Stories converted to tests are run in Jest and Playrite.
This feature can be used to smoke test the storybook, as well as to test whether the play function we looked at earlier was completed normally and whether there are any accessibility violations, so it can also be used to test UI components.

--- p.202

E2E testing on the front end allows for testing closer to the actual application because it can use a browser.
It is perfect for situations where you need to use browser-specific APIs or test while moving the screen.
(...) The most important thing in E2E testing is to clearly set the purpose of what to test.
The actual application connects to a database server or external storage service.
In E2E testing, an important criterion is how closely the entire structure, including these systems, can reproduce a realistic situation.

--- p.239