Episode 33: Back in the Testing Weeds with Sam Phippen and Justin Searls

Back in the Testing Weeds with Sam Phippen and Justin Searls
TableXI is now offering training for developers and products teams! For more info, email [email protected].
Get your FREE career growth strategy information and techniques! (https://stickynote.game)
Rails 5 Test Prescriptions (https://pragprog.com/titles/nrtest3) is updated, available, and shipping!
Guests
Sam Phippen (https://twitter.com/samphippen): Tech Lead at DigitalOcean (https://www.digitalocean.com/) and member of the RSpec (https://github.com/rspec) Core Team
Justin Searls (https://twitter.com/searls): Co-founder of Test Double (http://testdouble.com/)
Summary
I'm back in the testing weeds with Sam Phippen, lead maintainer for RSpec-Rails, and Justin Searls, co-founder of Test Double and author of testdouble.js. We talk about long-running test suites: are they bad, or just misunderstood? Does parallel CI solve all testing speed problems, or just some of them? Then we move to a wider view, what does it mean to test your library as part of a larger ecosystem. And, how can we leverage coverage or CI information to make for more useful testing tools over the lifetime of a project.
Notes
02:32 - Dealing with Longer and Longer Test Suites
- High Cost Tests and High Value Tests (http://confreaks.tv/videos/rubyconf2017-high-cost-tests-and-high-value-tests)
09:43 - What causes people to get into this trouble?
- On Writing Software Well #5: Testing without test damage or excessive isolation (https://youtu.be/Tc5z64XIwIY)
12:46 - If you had a fast test suite, would you still parallelize it in the CI?
15:12 - What does it mean for your library to still be functional?
- dont-break (https://www.npmjs.com/package/dont-break)
21:35 - Bugs found via the dont-break style of testing
- GRPC (https://grpc.io)
24:06 - Inferring which tests are run from a production code diff
29:31 - Coverage, what's it good for?
- RSpec (http://rspec.info/)
33:53 - What kind of features would you expect out of a CI-aware testing suite?
Related Episodes
Part I: Episode 004: In The Testing Weeds (http://www.techdoneright.io/004-testing-with-sam-and-justin) Special Guests: Justin Searls and Penelope Phippen.

Back in the Testing Weeds with Sam Phippen and Justin Searls

TableXI is now offering training for developers and products teams! For more info, email [email protected].

Get your FREE career growth strategy information and techniques!

Rails 5 Test Prescriptions is updated, available, and shipping!

Guests

Sam Phippen: Tech Lead at DigitalOcean and member of the RSpec Core Team
Justin Searls: Co-founder of Test Double

Summary

I'm back in the testing weeds with Sam Phippen, lead maintainer for RSpec-Rails, and Justin Searls, co-founder of Test Double and author of testdouble.js. We talk about long-running test suites: are they bad, or just misunderstood? Does parallel CI solve all testing speed problems, or just some of them? Then we move to a wider view, what does it mean to test your library as part of a larger ecosystem. And, how can we leverage coverage or CI information to make for more useful testing tools over the lifetime of a project.

Notes

02:32 - Dealing with Longer and Longer Test Suites

High Cost Tests and High Value Tests

09:43 - What causes people to get into this trouble?

On Writing Software Well #5: Testing without test damage or excessive isolation

12:46 - If you had a fast test suite, would you still parallelize it in the CI?

15:12 - What does it mean for your library to still be functional?

dont-break

21:35 - Bugs found via the dont-break style of testing

GRPC

24:06 - Inferring which tests are run from a production code diff

29:31 - Coverage, what's it good for?

RSpec

33:53 - What kind of features would you expect out of a CI-aware testing suite?

Related Episodes

Part I: Episode 004: In The Testing Weeds

Special Guests: Justin Searls and Penelope Phippen.