The art of writing mature tests

We all know how important testing is in SDLC but the last thing you want to do when you're building the next big thing is to struggle with tests. After writing and rewriting hundreds of tests, this is an attempt to save you from hours of frustration by sharing my learnings on how to write tests which don’t hold you back in innovating faster.

Transcript

1. The art of writing mature tests. Deepak Pathania Product Engineer, Postman PRESENTED BY @debugPathania
2. Motivation
 Frustration. - Writing a lot of tests and then modifying them all because of a slight change in the code base. - Spending more time fixing tests than writing code. - Going through tons of fixtures to debug failing tests.
3. Motivation
 Frustration. - Mocking and stubbing and faking and spying and crying. - Hoping Praying flaky tests don’t show up again in pipelines. - Staring at assertion failures and stack traces aimlessly.
4. What not to expect.
 ❌
5. Actions to improve current tests without drastic changes?
 ✅
6. Common mistakes and avoiding them.
7. 0. The test monolith ☠ - Neither unit nor integration. - High Coupling. No isolation. - Worst of both worlds.
8. 1. Asserting on deep equality.
9. http://www.chaijs.com/api/bdd/#method_include 1. Better way.
10. 2. Skipping ⏭
11. 2. Better way.
12. 3. Too many fixtures.
13. 3. Better way.
14. 4. Conditional logic
15. 4. Better way.
16. 5. Following poor spec 
 naming conventions. - Using the name of the function we are testing as the describe block text.
 - As a thumb rule for writing better descriptions, the describe-it block text should make a proper sentence.
 - A single test description should include the unit of work, the scenario and 
 the expected outcome.
17. 5 a.
18. 5 b.
19. https://dzone.com/articles/7-popular-unit-test-naming 5. Better way
20. 6. Deeper implementation levels.
21. 6. Better way
22. 7. Uncertainties
23. 7. Better way
24. 8. Separating declarations from usage.
25. 9. Dependence
26. 9. Better way
27. 10. Extra setup
28. 10. Better way
29. 11. Asserting on values without explanations.
30. 11. Better way
31. 12. Too many assertions
32. 12. Better way
33. Abstraction in tests
34. Test Design - Lay down constraints to define boundary. - Identify actors, scenarios and permutations. - Think first, test later.
35. Onboarding isn’t a nightmare.
36. Confidence against regressions.
37. Happy Testing. @debugPathania