From df6fbb416d70e8a4f8838e177becb0e77a5a9c43 Mon Sep 17 00:00:00 2001 From: dannyrb Date: Wed, 21 Aug 2019 23:06:30 -0400 Subject: [PATCH] docs: better pre-amble for testing doc --- docs/latest/contributing/testing.md | 35 +++++++++++++---------------- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git a/docs/latest/contributing/testing.md b/docs/latest/contributing/testing.md index 9d26bc82a..7c0b5f045 100644 --- a/docs/latest/contributing/testing.md +++ b/docs/latest/contributing/testing.md @@ -9,20 +9,20 @@ different. But do you know why we write tests? Do you know when to write one, or what kind of test to write? How do you know if a test is a _"good"_ test? This document's goal is to give you the tools you need to make those determinations. -Okay. So why do we write tests? To increase our... :drum:: +Okay. So why do we write tests? To increase our... **CONFIDENCE** -**CONFIDENCE** +- If I do a large refactor, does everything still work? +- If I changed some critical piece of code, is it safe to push to production? -> I want to be confident that the code I'm writing... won't break the app that I -> have running in production. So whatever I do, I want to make sure that the -> kinds of tests I write bring me the most confidence possible and I need to be -> cognizant of the trade-offs I'm making when testing. - Kent C. Dodds +Gaining the confidence we need to answer these questions after every change is +costly. Good tests allow us to answer them without manual regression testing. +What and how we choose to test to build that confidence is nuanced. ## Kinds of Tests Test's buy us confidence, but not all tests are created equal. Each kind of test has a different cost to write and maintain. An expensive test is worth it if it -gives us confidance that a payment is processed, but it may not be the best +gives us confidence that a payment is processed, but it may not be the best choice for asserting an element's border color. | Test Type | Example | Speed | Cost | @@ -32,6 +32,10 @@ choice for asserting an element's border color. | Integration | Clicking "Sign In", navigates to the dashboard (mocked network requests) | :running: Okay | :money_with_wings::money_with_wings::money_with_wings: | | End-to-end | Clicking "Sign In", navigates to the dashboard (no mocks) | :turtle: Slow | :money_with_wings::money_with_wings::money_with_wings::money_with_wings: | +- :rocket: Speed: How quickly tests run +- :money_with_wings: Cost: Time to write, and to debug when broken (more points + of failure) + ### Static Code Analysis Modern tooling gives us this "for free". It can catch invalid regular @@ -66,23 +70,21 @@ Where it falls short: That you're calling a dependency appropriately. ### Integration Tests -Integration tests take things one step further. You - -Where it falls short: That you're passing the right data to your backend. +We write integration tests to gain confidence that several units work together. +Generally, we want to mock as little as possible for these tests. In practice, +this means only mocking network requests. ### End-to-End Tests These are the most expensive tests to write and maintain. Largely because, when they fail, they have the largest number of potential points of failure. So why -do we write them? Because they also buy us the most confidance. +do we write them? Because they also buy us the most confidence. We should reserve end-to-end tests for mission critical features. A good example is testing user authentication. If a user can't sign in to your application, -it's an emergency. Having a high degree of confidance that users can always +it's an emergency. Having a high degree of confidence that users can always authenticate is very valuable. -Where it falls short: - #### When should we test? Mission critical features and functionality, or to cover a large breadth of @@ -91,11 +93,6 @@ feature `X` or scenario `Y`? Open an issue and let's discuss. ## Further Reading -Okay, so hopefully you have more confidance in your understanding of _why_ we -test, and the trade-offs we weigh when determining what kind of test should be -written. For the _how_, check out some of the links below, or read some of the -existing tests in this repository. - ### General - [Assert(js) Conf 2018 Talks][assert-js-talks]