Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Yoni Goldberg - enrich your node.js testing portfolio


Published on

We're going to discuss why the mainstream testing techniques (unit, integration, e2e) might fall short sometime and present 5 modern and useful alternatives

Why is this important? The vast majority of node.js testing tutorials deal only with unit or integration tests. While this is aligned with common best practices (e.g. the traditional testing pyramid), new voices doubt whether those are the right match for many projects, mostly because of their complexity and low ROI. As a result, new testing techniques emerge and provide an attractive alternative. In this session, we will discuss how to choose the right testing strategy for a project and demonstrate a handful of modern and fascinating techniques like property-based testing, consumer driven contacts (pact), component testing and more.

Important pre-requisites: We're going to compare some advanced (and neat) testing tools with the basics - it's recommended that you will make yourself familiar with the fundamentals of software testing: unit test, integration test, test-driven-development and the testing pyramid. Here are some suggested tutorials:

By Yoni Goldberg
Yoni is an independent Node.js architect consultant who works with customers in USA and Israel. Among his hobbies are writing about Node.js best practices in his blog and debugging node application using console.log. Read more about Yoni here:

Published in: Technology
  • Be the first to comment

Yoni Goldberg - enrich your node.js testing portfolio

  1. 1. Enrich Your Testing Portfolio
  2. 2. Me ● Independent consultant ● Backend & Node.js only ● Author of => ● ● debestpractices
  3. 3. Problem: an ancient pyramid drives our modern testing strategy ● Top R&D $$$ are assigned to quality and testing ● How we invest that money? Based on 10 years old model
  4. 4. 2014: It started with some provocative tweets
  5. 5. 2018: Leading voices put some doubt
  6. 6. Issue 1: Unit test has lower ROI (per unit) ● Would you paint a house using a mascara brush? ● Focus on exotic cases vs the critical path Unit Test Integration Tests
  7. 7. Issue2: the sum is greater than the parts ● Integration is often where the dead bodies are covered ● “But it worked on my machine” - Poke holes in reality ? ??
  8. 8. Issue2: the sum is greater than the parts ● Integration is often where the dead bodies are covered ● “But it worked on my machine” - Poke holes in reality ? ? ??
  9. 9. Issue 3: E2E tests are fragile & expensive ● Get confidence for an outrageous prices ● Re-build the entire AWS on your machine is tedious
  10. 10. Issue 4 : One technique fits all? ● Many different architecture - Data pipeline, UI meshup, deep learning models, IOT systems, etc, etc ● Tests need to solve real-world, not theoretic problems ● Where would you write unit tests here?
  11. 11. Solution #1: The Testing Trophy
  12. 12. Solution #2: Other modernized pyramids Spotify pyramid Testing quadrat
  13. 13. Solution #3: A rich testing portfolio ● Contextualize - suit tools for problems ● Diversify - rich and holistic approach
  14. 14. The portfolio #1: Component testing ● Problem: Finding the sweet spot between Unit and E2E ● Good for: Independent microservices ● Tools: HTTP interceptor (Nock), API tester (supertest) ● Can replace: Unit tests
  15. 15. Component testing - why I just love it ● Test what you deliver ● Use real internal resources, like db, Stub external collaborators ● Test entire flows -> Better confidence ● Less IO -> Better speed
  16. 16. Component testing: Stub the externals, boost the internals Stub the externalsBoost the internals
  17. 17. The portfolio #2: Consumer driven contracts ● Problem: many consumers - many API versions, Swagger is static, consumers don’t read the manual ● Good for: Integrations with complex and versioned API, multi- team microservices ● Framework: PACT ● Can replace: E2E tests
  18. 18. Consumer driven contract: the flow
  19. 19. PACT: The consumer expectations from the provider microservice
  20. 20. The provider verification code
  21. 21. View integration status within the broker
  22. 22. The portfolio #3: Property-based testing ● Problem: Traditional testing is based on selective and small set of input ● Good for: Loosely-typed APIs, serendipity ● Tools: jsverify, testcheck-js ● Can replace/improve: Unit & integration tests
  23. 23. Traditional testing -> manually code every input
  24. 24. Property based testing -> automatically invokes every possible permutation
  25. 25. Property based testing inside test case - example Invoked x times
  26. 26. Property based testing demands a shift of mind
  27. 27. Property based testing are great for: ● Generalize your expectations ○ E.g. Never get a price lower than 0 ● Validating generic health concerns ○ E.g. HTTP returns only 200, 204, 500 ○ Our code throws only valid Errors ○ Process never crash ○ No DDOS ● Great match for loose API ○ E.g. search systems, IOT ● Prepare the ground for unit testing
  28. 28. The portfolio #4: Mutation-based testing ● Problem: Testing coverage doesn’t measure the test effectiveness ● Good for: Revealing bugs in logic-heavy apps ● Tools: Stryker ● Can improve: Unit & integration test
  29. 29. 83% coverage - isn’t this great?
  30. 30. 83% coverage and 0 expectations. This isn’t great
  31. 31. Stryker can measure test efficiency
  32. 32. The portfolio #5: Chaos testing ● Problem: Bad things might come from outside ● Good for: Companies that value resilience ● Tools: Netflix swiss army knife, kube-monkey, node-chaos- monkey ● Can improve: E2E tests
  33. 33. The typical container-killer monkey
  34. 34. Node.js in-process chaos tool
  35. 35. Wrapping up ● Some testing tools suit your needs better ● Lean testing is a great companion for lean teams ● Wanna benefits all these goods? Enrich your testing portfolio P.s. we haven’t discussed ‘Acceptance testing’, ‘VCR testing’, ‘Database testing’, ‘Shadow testing’ and others