全面详尽的 JavaScript 和 Node.js 测试最佳实践（2023 年 7 月）.zip

<img src="/assets/jtbp-header-blue.png" width="1920px"/> <br/> # 👇 Why this guide can take your testing skills to the next level <br/> ## 📗 50+ best practices: Super-comprehensive and exhaustive This is a guide for JavaScript & Node.js reliability from A-Z. It summarizes and curates for you dozens of the best blog posts, books, and tools the market has to offer ## 🚢 Advanced: Goes 10,000 miles beyond the basics Hop into a journey that travels way beyond the basics into advanced topics like testing in production, mutation testing, property-based testing, and many other strategic & professional tools. Should you read every word in this guide your testing skills are likely to go way above the average ## 🌐 Full-stack: front, backend, CI, anything Start by understanding the ubiquitous testing practices that are the foundation for any application tier. Then, delve into your area of choice: frontend/UI, backend, CI, or maybe all of them? <br/> ### Written By Yoni Goldberg - A JavaScript & Node.js consultant ### 👨‍🏫 Exciting news: I've just released my super-comprehensive testing course after two years of recording and editing. [Less than 48 hours left for the 🎁 special launch deal](https://testjavascript.com/) <br/> ### Translations - read in your own language - 🇨🇳[Chinese](readme-zh-CN.md) - Courtesy of [Yves yao](https://github.com/yvesyao) - 🇰🇷[Korean](readme.kr.md) - Courtesy of [Rain Byun](https://github.com/ragubyun) - 🇵🇱[Polish](readme-pl.md) - Courtesy of [Michal Biesiada](https://github.com/mbiesiad) - 🇪🇸[Spanish](readme-es.md) - Courtesy of [Miguel G. Sanguino](https://github.com/sanguino) - 🇧🇷[Portuguese-BR](readme-pt-br.md) - Courtesy of [Iago Angelim Costa Cavalcante](https://github.com/iagocavalcante) , [Douglas Mariano Valero](https://github.com/DouglasMV) and [koooge](https://github.com/koooge) - 🇫🇷[French](readme-fr.md) - Courtesy of [Mathilde El Mouktafi](https://github.com/mel-mouk) - 🇯🇵[Japanese (draft)](https://github.com/yuichkun/javascript-testing-best-practices/blob/master/readme-jp.md) - Courtesy of [Yuichi Yogo](https://github.com/yuichkun) and [ryo](https://github.com/kawamataryo) - 🇹🇼[Traditional Chinese](readme-zh-TW.md) - Courtesy of [Yubin Hsu](https://github.com/yubinTW) - 🇺🇦[Ukrainian](readme-ua.md) - Courtesy of [Serhii Shramko](https://github.com/Shramkoweb) - 🇮🇷[Persian](readme-pr-fr.md) - Courtesy of [Ali Azmoodeh](https://github.com/TREER00T) - 🇷🇺[Russian](readme-ru.md) - Courtesy of [Alex Popov](https://github.com/Saimon398) - Want to translate to your own language? please open an issue 💜 <br/><br/> ## `Table of Contents` #### [`Section 0: The Golden Rule`](#section-0️⃣-the-golden-rule) A single advice that inspires all the others (1 special bullet) #### [`Section 1: The Test Anatomy`](#section-1-the-test-anatomy-1) The foundation - structuring clean tests (12 bullets) #### [`Section 2: Backend`](#section-2️⃣-backend-testing) Writing backend and Microservices tests efficiently (13 bullets) #### [`Section 3: Frontend`](#section-3️⃣-frontend-testing) Writing tests for web UI including component and E2E tests (11 bullets) #### [`Section 4: Measuring Tests Effectiveness`](#section-4️⃣-measuring-test-effectiveness) Watching the watchman - measuring test quality (4 bullets) #### [`Section 5: Continuous Integration`](#section-5️⃣-ci-and-other-quality-measures) Guidelines for CI in the JS world (9 bullets) <br/><br/> # Section 0️⃣: The Golden Rule <br/> ## ⚪️ 0 The Golden Rule: Design for lean testing :white_check_mark: **Do:** Testing code is not production-code - Design it to be short, dead-simple, flat, and delightful to work with. One should look at a test and get the intent instantly. See, our minds are already occupied with our main job - the production code. There is no 'headspace' for additional complexity. Should we try to squeeze yet another sus-system into our poor brain it will slow the team down which works against the reason we do testing. Practically this is where many teams just abandon testing. The tests are an opportunity for something else - a friendly assistant, co-pilot, that delivers great value for a small investment. Science tells us that we have two brain systems: system 1 is used for effortless activities like driving a car on an empty road and system 2 is meant for complex and conscious operations like solving a math equation. Design your test for system 1, when looking at test code it should _feel_ as easy as modifying an HTML document and not like solving 2X(17 × 24). This can be achieved by selectively cherry-picking techniques, tools, and test targets that are cost-effective and provide great ROI. Test only as much as needed, and strive to keep it nimble, sometimes it's even worth dropping some tests and trading reliability for agility and simplicity.  Most of the advice below are derivatives of this principle. ### Ready to start? <br/><br/> # Section 1: The Test Anatomy <br/> ## ⚪ ️ 1.1 Include 3 parts in each test name :white_check_mark: **Do:** A test report should tell whether the current application revision satisfies the requirements for the people who are not necessarily familiar with the code: the tester, the DevOps engineer who is deploying and the future you two years from now. This can be achieved best if the tests speak at the requirements level and include 3 parts: (1) What is being tested? For example, the ProductsService.addNewProduct method (2) Under what circumstances and scenario? For example, no price is passed to the method (3) What is the expected result? For example, the new product is not approved <br/> ❌ **Otherwise:** A deployment just failed, a test named “Add product” failed. Does this tell you what exactly is malfunctioning? <br/> **👇 Note:** Each bullet has code examples and sometime also an image illustration. Click to expand <br/> <details><summary>✏ <b>Code Examples</b></summary> <br/> ### :clap: Doing It Right Example: A test name that constitutes 3 parts  ```javascript //1. unit under test describe('Products Service', function() { describe('Add new product', function() { //2. scenario and 3. expectation it('When no price is specified, then the product status is pending approval', ()=> { const newProduct = new ProductService().add(...); expect(newProduct.status).to.equal('pendingApproval'); }); }); }); ``` <br/> ### :clap: Doing It Right Example: A test name that constitutes 3 parts  </details> <br/> <details><summary>© <b>Credits & read-more</b></summary> 1. <a href='https://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html'>Roy Osherove - Naming standards for unit tests</a> </details> <br/><br/> ## ⚪ ️ 1.2 Structure tests by the AAA pattern :white_check_mark: **Do:** Structure your tests with 3 well-separated sections Arrange, Act & Assert (AAA). Following this structure guarantees that the reader spends no brain-CPU on understanding the test plan: 1st A - Arrange: All the setup code to bring the system to the scenario the test aims to simulate. This might include instantiating the unit under test constructor, adding DB records, mocking/stubbing on objects, and any other preparation code 2nd A - Act: Execute the unit under test. Usually 1 line of code 3rd A - Assert: Ensure that the received value satisfies the expectation. Usually 1 line of code <br/> ❌ **Otherwise:** Not only do you spend hours understanding the main code but what should have been the simplest part of the day (testing) stretches your brain <br/> <details><summary>✏