├── prettier.config.js └── slides ├── 00.jpg ├── 01.md ├── 02.md ├── 03.md ├── 04.md ├── 05.md ├── 06.md ├── 07.md ├── 08.md ├── 09.md ├── 10.md ├── 11.md └── 12.md /prettier.config.js: -------------------------------------------------------------------------------- 1 | process.env.RUNNING_PRETTIER = 'true' 2 | module.exports = { 3 | arrowParens: 'avoid', 4 | bracketSpacing: false, 5 | embeddedLanguageFormatting: 'auto', 6 | endOfLine: 'lf', 7 | htmlWhitespaceSensitivity: 'css', 8 | insertPragma: false, 9 | jsxBracketSameLine: false, 10 | jsxSingleQuote: false, 11 | printWidth: 80, 12 | proseWrap: 'always', 13 | quoteProps: 'as-needed', 14 | requirePragma: false, 15 | semi: false, 16 | singleQuote: true, 17 | tabWidth: 2, 18 | trailingComma: 'all', 19 | useTabs: false, 20 | } 21 | -------------------------------------------------------------------------------- /slides/00.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kentcdodds/what-test-slides/53989b119110d4765875e2e7034d438ec86316e8/slides/00.jpg -------------------------------------------------------------------------------- /slides/01.md: -------------------------------------------------------------------------------- 1 | # How to know what to test 2 | 3 | > Just make that coverage report say 100% right? 4 | 5 | 👋 I'm Kent C. Dodds 6 | 7 | - Slides https://github.com/kentcdodds/what-test-slides 8 | - Blog post: https://kentcdodds.com/blog/should-i-write-a-test-or-fix-a-bug 9 | - 🏡 Utah 10 | - 👩 👧 👦 👦 👦 🐕 11 | - 🏢 https://kentcdodds.com 12 | - 🐦/🐙 @kentcdodds 13 | - 🏆 https://TestingJavaScript.com 14 | - 👨‍🚀 https://EpicReact.dev 15 | - 💻 https://kcd.im/workshops 16 | - 🎙 https://kcd.im/podcast 17 | - 💌 https://kcd.im/news 18 | - 📝 https://kcd.im/blog 19 | - 💖 https://kcd.im/discord 20 | - 📽 https://kcd.im/youtube 21 | -------------------------------------------------------------------------------- /slides/02.md: -------------------------------------------------------------------------------- 1 | # What this talk is 2 | 3 | - TestingJavaScript.com taught us "how" - This talk will tell us "what" 4 | 5 | # What this talk isn't 6 | 7 | - 🤷‍♂️ 8 | -------------------------------------------------------------------------------- /slides/03.md: -------------------------------------------------------------------------------- 1 | # Remember this? 2 | 3 | > The more your tests resemble the way your software is used, the more 4 | > confidence they can give you. 5 | > 6 | > – [me](https://twitter.com/kentcdodds/status/977018512689455106) 7 | 8 | **We write tests to be confident that our application will work when the user 9 | uses them.** 10 | -------------------------------------------------------------------------------- /slides/04.md: -------------------------------------------------------------------------------- 1 | # The key takeaway: 2 | 3 | **Think less about the code you are testing and more about the use cases that 4 | code supports.** 5 | 6 | Otherwise you might accidentally start testing 7 | [implementation details](https://kentcdodds.com/blog/testing-implementation-details)! 8 | 😱 9 | 10 | ---> `Code < Use Cases` <--- 11 | 12 | 1. Code changes more often than use cases do. 13 | 2. The code can be "working" when the use case is broken. 14 | -------------------------------------------------------------------------------- /slides/05.md: -------------------------------------------------------------------------------- 1 | # Code Coverage < Use Case Coverage 2 | 3 | What does code coverage tell us? 4 | 5 | What does code coverage NOT tell us? 6 | 7 | ## When looking at code... 8 | 9 | Don't think about the ifs/elses, loops, or component lifecycles. That's code 10 | coverage... 11 | 12 | Instead ask yourself: 13 | 14 | > What use cases are these lines of code supporting, and what tests can I add to 15 | > support those use cases? 16 | 17 | That's use case coverage. 18 | -------------------------------------------------------------------------------- /slides/06.md: -------------------------------------------------------------------------------- 1 | # Code coverage can hide use cases 2 | 3 | ```ts 4 | function arrayify(maybeArray) { 5 | if (Array.isArray(maybeArray)) { 6 | return maybeArray 7 | } else { 8 | return [maybeArray].filter(Boolean) 9 | } 10 | } 11 | ``` 12 | 13 | ```ts 14 | test('returns an array if given an array', () => { 15 | expect(arrayify(['Elephant', 'Giraffe'])).toEqual(['Elephant', 'Giraffe']) 16 | }) 17 | ``` 18 | 19 | ```ts 20 | test(`returns an array with the given argument if it's not an array`, () => { 21 | expect(arrayify('Leopard')).toEqual(['Leopard']) 22 | }) 23 | ``` 24 | 25 | With those two tests, guess what our coverage report looks like. 26 | 27 | What would our theoretical use case coverage report look like? Yup, we need 28 | another test! 29 | 30 | ```ts 31 | test('returns an empty array if given a falsy value', () => { 32 | expect(arrayify()).toEqual([]) 33 | }) 34 | ``` 35 | 36 | Yes, you could write this function differently... I know, I know. 37 | -------------------------------------------------------------------------------- /slides/07.md: -------------------------------------------------------------------------------- 1 | # Test use cases, not code. 2 | -------------------------------------------------------------------------------- /slides/08.md: -------------------------------------------------------------------------------- 1 | # React 2 | 3 | Don't think about: 4 | 5 | - Lifecycle methods 6 | - Element event handlers 7 | - Internal Component State 8 | 9 | Think about your two users (devs and end users): 10 | 11 | - User interactions (using `userEvent` from `@testing-library/user-event`): 12 | - **What happens** when the end user interacts with the elements that the 13 | component renders? 14 | - Changing props (using `rerender` from `@testing-library/react`): 15 | - **What happens** when the developer user re-renders your component with new 16 | props? 17 | - Context changes (using `rerender` from `@testing-library/react`): 18 | - **What happens** when the developer user changes context resulting in your 19 | component re-rendering? 20 | - Subscription changes: 21 | - **What happens** when an event emitter the component subscribes to changes? 22 | (Like firebase, a router, a media query, or browser-based subscriptions like 23 | online status) 24 | -------------------------------------------------------------------------------- /slides/09.md: -------------------------------------------------------------------------------- 1 | # Where to start 2 | 3 | Ask yourself: 4 | 5 | > What part of this app would make me most upset if it were broken? 6 | 7 | Alternatively: 8 | 9 | > What would be the worst thing to break in this app? 10 | 11 | Make a list with the product manager! 12 | 13 | Read: 14 | [How to add testing to an existing project](https://kentcdodds.com/blog/how-to-add-testing-to-an-existing-project) 15 | -------------------------------------------------------------------------------- /slides/10.md: -------------------------------------------------------------------------------- 1 | # Conclusion 2 | 3 | - We write tests to be confident that our application will work when the user 4 | uses them. 5 | - Think less about the code you are testing and more about the use cases that 6 | code supports. 7 | - `Code < Use Cases` -> `Code Coverage < Use Case Coverage` 8 | - Test use cases, not code. 9 | -------------------------------------------------------------------------------- /slides/11.md: -------------------------------------------------------------------------------- 1 | # Resources 2 | 3 | - [Testing Implementation Details](https://kentcdodds.com/blog/testing-implementation-details) 4 | - [Avoid the Test User](https://kentcdodds.com/blog/avoid-the-test-user) 5 | - [How to add testing to an existing project](https://kentcdodds.com/blog/how-to-add-testing-to-an-existing-project) 6 | - [Static vs Unit vs Integration vs E2E Testing for Frontend Apps](/blog/unit-vs-integration-vs-e2e-tests) 7 | - [Aaron Abramov's](https://twitter.com/aarondjents) talk at 8 | [AssertJS 2018](http://web.archive.org/web/20180411223419/https://www.assertjs.com/): 9 | [Establishing testing patterns with software design principles](https://youtu.be/_pnW-JjmyXE?list=PLZ66c9_z3umNSrKSb5cmpxdXZcIPNvKGw) 10 | 11 | Oh... and [TestingJavaScript.com](https://testingjavascript.com) 12 | -------------------------------------------------------------------------------- /slides/12.md: -------------------------------------------------------------------------------- 1 | # Thank you! 2 | 3 | 👋 4 | 5 | 🐦 @kentcdodds 6 | 7 | 💌 https://kentcdodds.com/subscribe 8 | 9 | Slides: https://github.com/kentcdodds/what-test-slides 10 | --------------------------------------------------------------------------------