Testing

Testing as rapid feedback

• What do others do without tests? • Argues that the primary purpose of testing can be giving yourself quicker feedback while developing and debugging than you can get from a REPL, debugger or browser • Thorsten Ball 📖

Testing features, not code

• How to Test • Alex Kladov 📖

Test-Driven Development

• Canon TDD • “Write a list of the test scenarios you want to cover. Turn exactly one item on the list into an actual, concrete, runnable test. Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them). Optionally refactor to improve the implementation design.” • Kent Beck 📖
• TDD for those who don’t need it • Funny talk showing how to use TDD to loop through a declarative list of requirements you list up front • Chew Choon Keat 📺
• TDD, Where Did It All Go Wrong? • How to apply TDD as originally intended and avoid bad practices like testing implementation details instead of required behaviours • Ian Cooper 📺
• TDD: The Bad Parts • Identifies bad testing practices to avoid and includes tips like pairing tests with behaviours, not files • Matt Parker 📺
• Five Underplayed Premises Of TDD | Video • GeePaw Hill 📖
• TDD • Questions whether TDD leads to building the right thing when you first need to explore a problem before deciding how to solve it • The Primeagen 📺

Playwright

• Playwright 🛠️
• Cross Browser AUTOMATION and TESTING using PLAYWRIGHT • Basarat Ali 📺
• What is HTTP Authentication and how to automate it with Playwright • Basarat Ali 📺
• Automating user interactions in a browser using Playwright • Basarat Ali 📺
• Scraping and Verifying the contents a webpage using Playwright • Basarat Ali 📺
• Mocking, Intercepting, Monitoring and Waiting for network requests with Playwright • Basarat Ali 📺
• Eliminating and Debugging Flaky Integration Tests • Builder.io 📖

Testing in production

• Testing in Production • How to test in production using feature flags and canary releases • Talia Nassi 📺
• Set Up Feature Flags with React in 10 Minutes • Talia Nassi 📰

API Testing

• Thunder Client • Lightweight Rest API Client Extension for VS Code 🛠️
  • How to do API Testing in VS Code • Visual Studio Code
• Postman 🛠️
• Insomnia 🛠️
• Paw 🛠️
• HTTPie 🛠️
• curl 🛠️

Model-based testing

• Model-Based Testing in React with State Machines • David Khourshid 📖
• First steps in Model-based testing • Adam Sanderson 📖
• @xstate/test • XState docs 📚
• Reuse functional state machine, or create separate version for tests? • davidkpiano/xstate-test-demo 💬

Inbox

• unit testing made easier by refactoring all functions to be pure (even if some inputs never change while the app runs):

  • pure functions are easier to test than functions that read values from the environment (e.g. variables defined outside the function as env vars, top-level file vars, etc)
  • but sometimes some of those input values won’t actually change from one call to the next (e.g. config values that remain the same during the life of the app process that are read in middleware functions that run before/after each request to that app)
  • for unit testing purposes, it’s nice if all those used values are passed as inputs that can be easily faked
  • however for performance purposes, it may be costly to recompute the same values each time the function is called
  • option 1: read values defined at file level inside the function, stop passing them in as args, and mock those global values in the test
    • can require very annoying mocking boilerplate depending on which test framework you’re using and where those values are coming from
  • option 2: continue passing those values as args, but make them optional args with their default values set to those file-level definitions
    • benefits: compute those default values once + app itself never passes those optional args (simpler function calls) + test gets to override those optional args with whatever fake values are useful for simulating changes in the config/env, etc
  • got this idea from MH in this helpful PR review thread

• Unlighthouse - open source tool to run Lighthouse on every page on a site in seconds with one command

• Welcome to Pytest with Eric! | Pytest with Eric

• flask: Testing Flask Applications with Pytest | TestDriven.io

• pytest: fixtures: 8 Powerful Features You Didn’t Know About the Fixtures of Pytest - Explains that in the body of a fixture, everything before yield runs before the test(s) as setup, while everything after runs afterwards as teardown

• pytest: fixtures: pytest: everything you need to know about fixtures (intermediate) anthony explains - anthonywritescode

• An introduction to property based testing | F# for fun and profit • Scott Wlaschin 📖

• Choosing properties for property-based testing | F# for fun and profit • Scott Wlaschin 📖

• A Few Words on Testing - by Thorsten Ball - Register Spill • Not all code needs tests • Thorsten Ball 📖

• How to Test • Includes many actionable ideas, including focusing on testing features instead of code and making the code under test easier to change by using snapshot testing and a check function • matklad 📖

• ongoing by Tim Bray · Testing in the Twenties • Test absolutely everything you can because future developers will thank you • Tim Bray 📖

• Test Driven Development • Start by writing a list of all the test cases you can think of, then keep that list updated as you learn and implement your unit’s behavior one test case at a time • Martin Fowler 📖

• Canon TDD - by Kent Beck - Software Design: Tidy First? • The best summary from the best source • Kent Beck 📖

• asatarin/testing-distributed-systems: Curated list of resources on testing distributed systems • 📖

• ivanyu/awesome-deterministic-simulation-testing: A curated list of awesome deterministic simulation testing resources 😎 • 📖

• asatarin/testing-distributed-systems: Curated list of resources on testing distributed systems • 📖