Achieving peace of mind through test coverage

In this talk we are going to see how to efficiently implement tests in order to achieve a consistent and reliable release strategy that will allow all your team members to sleep at night.

Presented at http://js-montreal.org/ meetup of October 2019.

Git repo containing the demo presented can be find here: https://github.com/ruyadorno/the-one-with-test-coverage

Transcript

1. Achieving peace of mind through test coverage js-montreal 10/2019
2. Ruy Adorno @ruyadorno OSS Dev @
4. Intro Tests are an essential tool that helps alleviate the task of maintaining a code base. They give us confidence when shipping new releases of a program by providing an automate assessment into its expected set of features. My hope with this talk is to enlighten on how coverage of code is important and provide practical tips on how to test more of your code.
5. What is a test? • Program that runs your code • Validates your expectations • Makes sure things behave the way they should
6. Benefits: • Reliability, you want to know about defects as soon as possible • Approachability, people can tweak your code and know if they break it • Quality, teams end up finding improvements and optimizations
7. Coverage • Metric, it tracks what parts of your program actually executed • Doesn’t prove that the test suite is good • That can serve as a test itself
8. Benefits: • In order to achieve higher coverage you have to dig deeper into the internals • Help to uncover bugs, serves as documentation to all program details • Serves as confidence meter for that code
9. Mergebot • Github bot • Controls merging PRs • Front End cli scripts
10. • Let’s go through some examples of helpful patterns while trying to bump test coverage Useful patterns:
11. Snapshots
12. Snapshots • Useful when testing verbose output • pros: Extra convenient to work with • cons: requires way more discipline
13. Patch APIs
14. Patch APIs • Allow us to assert for specific internal calls (specially global)
15. Abstractions
16. Abstractions • Abstract hard to test internals into separated function/modules
17. Mocking modules
18. Mocking modules • Cleaner solution to checking to internal calls • Test frameworks tend to provide simpler to use APIs for those
19. node-tap
20. node-tap • Different test frameworks provide a different set of APIs but conceptually they all share the same ideas
21. node-tap
22. node-tap • One very convenient design choice of node-tap is allowing to run tests without the need of a top-level runner • Makes it so much easier to start debugging your tests
23. It may be difficult to get coverage up, specially when reaching to parts of your codebase in which are harder to test by the very nature of the code there. I hope the patterns I share here help you on the task of covering more features of your code base using automated tests. Conclusion:
24. process.exit(0) https://ruyadorno.com Thanks!
25. Photo Credits • Photo by Kari Shea on Unsplash • Photo by Grzegorz Mleczek on Unsplash • Photo by rawpixel on Unsplash • Photo by Aidan Hancock on Unsplash