Testing in an Engineering Organization
Testing, the most opinionated topic at any engineering organization. For good reasons. Historically, if you look at how programming languages are designed, testing has always been secondary — an afterthought. While formlessness creates innovative ideas for new and better way of getting things done, formlessness creates the un-opinionated wild west. We’re un-scalable when opinions strive.
We don’t argue discuss whether we should write “method” or “function”
in Java when we’re only allowed to define subroutines through the symbol: “method”.
For engineering to scale, we need strong, versioned standards—norms that are defined and enforced.
We iterate the standards; just like how you would iterate your implementation.
Writing Unit Tests
“The purpose of unit tests is to test each unit of code in isolation from the rest of the code to quickly pinpoint where code is and isn’t working as expected. You’ll put unit tests in the src directory in accompanying each file with the code that they’re testing.” - rust
Writing Integration Tests
“Unit tests do have one major disadvantage: even if the units work well in isolation, you do not know if they work well together. An integration test takes a small group of units, often two units, and tests their behavior as a whole, verifying that they coherently work together.” - Google
Writing End-to-end Tests
End-to-end testing verifies that our software works correctly from the beginning to the end of a particular user flow. It replicates expected user behavior and various usage scenarios to ensure that your software works as a whole. End-to-end testing should mimic (as much as possible) a production equivalent environment and data to simulate real-world situations.
Coverage as a Metric?
Coverage is just a vanity metric. It’s a metric that is easily gamed. It’s a metric that is easily misunderstood. It’s a metric that is easily misused to serve your own agenda and ego.