Skip to content
0:00 / 0:00

#integrationtesting#unittesting#testingtrophy

Kent C. Dodds – Write tests. Not too many. Mostly integration.

Paul Dowman's tech events and interviews

2.6K subscribers • 1 video on Hallway

YouTube
  • Recommended by 3 people: 3 in engineering communities.
  • A classic. People kept recommending it from 2018 to 2024.
  • Presented by Kent C. Dodds
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

59K views8 years ago3 recommendations

Tools and practiceTesting

Kent C. Dodds discusses the value of automated testing and why developers should focus their efforts on integration tests.

assertjs.com Automated tests are an important part of raising your confidence when releasing software. They can speed you up or slow you down depending on how you write them and which form of testing you focus your test writing on. In this talk, we’ll cover the value of automated testing and where your efforts should be focused to strike the best balance of confidence and effort. OK GROW! is the founding sponsor of AssertJS. To learn more about how we can help you build better products visit: okgrow.com

Why it's here

3 people recommend this

What people say. Recommended as an excellent and entertaining talk on balancing the cost and confidence of automated testing.

u/Stettoin r/node • Recommends

On “E2E Tests Taking Too Long. How you guys do it?”

You're just starting to realize, that E2E-tests are expensive. They require your whole application, interace with a real browser and are generally slower than alternatives. Tests are supposed to give confidence, that you didn't introduce critical bugs into your application. But tests also have a cost and in the case of E2E, that's: time, infrastructure costs and flakiness. Kent C. Dodds held a great, entertaining talk about that. If you attempt to cover all of your testing requirements with e2e-tests that will inevitably slow you down. Try to build more pure API and pure frontend tests. They run way faster and you can even decide to run them context specific. As in: "Only one specific…

u/F4ze0nein r/Frontend • Recommends

On “Do we really need unit test for front end ?”

Test for confidence in your application. In the end you control what's needed. link

u/roboctocatin r/node • Recommends

On “How to test my api?”

…atch any bugs? 2. Will it prevent developers from injecting new bugs? 3. Will it strengthen unavoidably brittle code? 4. Will it help maintain unavoidably complex algorithms? 5. Will it test corner cases? 6. For weakly typed languages, will it help maintain correct type usage? On top of all this I'd recommend you check out following presentation [video Writing unit test for an endpoint where you have to mock response is IMO not that beneficial. Writing test that tests and endpoint and return result from db that you can verify gives you a lot more mileage. Jest gives you everything you need. No need for additional libraries.…