Writing tests is not fun. But I believe that self-testing is an important part of the quality assurance system, and an important tool to ensure that you will not be constantly disturbed by strange questions when you finish writing the program.
Isn’t it irksome to think about how confident you’ve left your project to the testers, only to be forced to stop and go back to work because of a bug that gets in the way?
Another friend of the team changed a function that had nothing to do with me. As a result, because he moved a common component, the part I was in charge of was also broken. The product and test were in a rush to ask me what was going on.
The unpleasantness of writing tests is nothing by comparison.
Functional unit testing
I’ve been practicing functional unit testing for quite some time. From force yourself to use valuable time to increase a few I have passed the test validation in the browser, to write a small library to implement smoothly without professional test under the protection of the junior barely write test, or one’s fingers itch to reconstruct but not to disturb the giant busy testing bosses with test results from the card, and then to meet bug add test cases to avoid happen again…
At present, the written library, NodeJS CLI tools and so on basically rely on the testing framework to observe the mode, CI automated test verification effect. The productivity gains and bug fixes are great, and unit testing is highly recommended for all common functions!
Testing frame view mode allows me to quickly see the results of code execution without having to repeatedly switch the active window elsewhere:
Editor support also allows me to interrupt point-to-point debugging directly inside:
As long as I write a function that is “pure”, testing helps me ensure that the output I specify is the output I expect. I can safely rely on this function to narrow down the potential for bugs.
What happens to UI business components?
The PARTS that involve UI, like the React Component, I haven’t dared to try. The main reason is that instability increases exponentially once UI is involved. Not only are products and designs often tweaked to improve the user experience, but refining a scalable UI component is harder than refining a function, and testing is complicated by our dependence on different frameworks. So big guys like this one wrote a unit test retreat. Simply said the voice, I have been so to persuade their 🤷♀️.
In theory, however, it is nothing more than a function, just input and output, except that it is more asynchronous than a function and has more external dependencies, CSS, graphics, UI frames, and so on, all of which can cause bugs.
Should we test the UI and business components at all? I asked myself a thousand times, but no answer. Until I watched a series of videos of test guru Kent C introducing front-end test-driven development using the React-Testing library, which he helped organize, I found that testing was not as troublesome as I thought before.
Consider also that the concern about components being constantly modified may be addressed by a case-by-case discussion. If you’re dealing with a one-time, short-term project with no need for long-term maintenance changes, it may not be wise to spend time writing tests.
If you have a project that needs to be maintained for a long time, especially if you have multiple people working on it, changing pages, modules, adding bits, deleting bits, getting more complex, and components increasingly interdependent and coupled, you should consider writing component unit tests.
There are still tweaks and tweaks to such projects, but there is always a part of the project that “sinks” and becomes stable: the public or business common components that are much more dependent on them. These components are so much more dependent and burdened that they would rather build a similar one than move. With all-round, multi-angle testing, you can open up a bit and adapt to new requirements while doing a good job of backward compatibility. Therefore, I recommend writing unit tests only for common components that rely a lot.
Finally, in common components, you can also consider omitting a component that has no logic, just wraps a layer on top of another component, or simply uses a component that combines multiple components for convenience. Testing them is not as good as testing the components they call.
What do component unit tests measure?
When it comes to component testing, I think of the following:
-
Does the test show that it meets the requirements of the design draft?
-
Test the function, the display can display, the trigger can trigger?
-
Test the interaction, can it go through according to the product requirements?
The first point shows that I think it is more difficult to define programmatically, apart from the technical difficulty, how much difference is acceptable is entirely determined by human subjective feelings. Unless not a single pixel can be lost. , this can be considered program screenshot comparison. Or have a standard range of rules such as what color wireframes must be (in fact, it is difficult for designers to unify their own styles…). , only part of the style specified in the standard is tested. The problem is that style is also affected by component context, so unit testing doesn’t make much sense, and integration testing might be considered.
The second function, and the third interaction, are important in common components. However, if the interaction part of your development uses a reliable state machine such as xState, you might consider model-based testing — each interaction is simply a transition from one state to another, with the transition state managed by the state machine, as long as the state machine configuration is correct. But getting used to a state machine designed by someone else can be exhausting.
summary
To summarize the points of this article:
- It is strongly recommended to write unit tests for functions to keep them as “clean” as possible and avoid instability
- For long-term maintenance projects, it is recommended to write unit tests for common components
- Unit testing of components focuses on measuring functionality and interaction
Check out the other test series:
- The React application test: configuration Typescript, Jest, ESLint | creator training camp
- React -testing-library quickly tests react component renderings
- Jest test CSS Module component error how to do?
- Isolate uncontrollable factors in unit tests with Jest Mock
- Use react-testing-library to quickly test react component interactions
Post title XXX | creator training camp The campaign is under way…