Software Engineering At Google
Chapter #11 - Testing Overview (2 of 3)
Software Engineering at Google Chapter #11 - Testing Overview (2 of 3)
The benefits of testing Code:
Less debugging - The more and better tests exist, the less overall debugging that needs to be done
Increased confidence in changes - Indeed
Improved documentation - Tests function as "executable documentation"
Simpler code reviews - The reviewer spends less mental effort if tests are include, they do the checks for him/her
Thoughtful design - Creating tests may make one re-think design decisions
Fast and high quality releases - Release with confidence via testing
Ideally, code refactors should not require changes to existing tests
Smaller tests are overall less painful than larger ones, make them small as you can
A non-deterministic test is one that does not have a "finite" outcome and may run forever
The "scope" of a test is the code path(s) that it exercises
Executing a line of code is not the same as verifying that it works as expected (it may run, but it runs incorrectly)
At Google, engineers specify the test size (small, medium, large) in terms of CPU + memory
Test sizes allow for guarantees about stability, speed, and resource utilization
They do this instead of traditional unit + integration tests because they always want to optimize for speed
Google's "small tests" are a single process or thread, you can't connect to external things (DB)
The small tests are limited in scope so that engineers don't do non-deterministic things in them
Small tests keep the test suite running quickly and reliably, they are preferred
Medium tests can do multi-process stuff and talk to localhost (no external network connections allowed)
Large tests allow external network connections but with the tradeoff of them being slower and more flakey
Thank you for your time and attention.
Apply what you've learned here.
Enjoy it all.
© 2021 Josh Turgasen
All product names, logos, and trademarks are property of their respective owners