Titus Winters and Hyrum Wright share testing philosophies and common mistakes based on maintaining Google's massive C++ codebase.
Cppcon.org
—
Titus Winters & Hyrum Wright
"All Your Tests are Terrible: Tales from the Trenches"
--
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/cppcon/cppcon2015
—
Thousands of Google engineers have collectively written about 100,000 separate C++ test binaries in the last 15 years. Not all of those was a perfect test. In this talk we’ll focus on how to write good tests and adopt a good testing philosophy, with lots of examples of what not to do (and why).
—
Titus Winters has spent the past 4 years working on Google's core C++ libraries. He's particularly interested in issues of large scale software engineer and codebase maintenance: how do we keep a codebase of over 100M lines of code consistent and flexible for the next decade? Along the way he has helped Google teams pioneer techniques to perform automated code transformations on a massive scale, and helps maintain the Google C++ Style Guide.
Hyrum Wright hates C++ less than the rest of the programming languages he's worked with, and works on C++ library infrastructure at Google. He writes programs to rewrite other programs, and will eventually put himself out of a job. In a former life, he was an author of Apache Subversion, and still retains membership in the Apache Software Foundation. Hyrum enjoys cycling, but didn't bring a bike to Seattle. Twitter handle: @hyrumwright
—
Videos Filmed & Edited by Bash Films: BashFilms.com
Work at Hudson River Trading (HRT): tinyurl.com/safxfctf
Why it's here
2 people recommend this
What people say. Recommended as an excellent talk on unit testing philosophy and codebase maintenance.
a
u/aruisdantein r/ExperiencedDevs • Recommends
On “How do you stop PR bottlenecks from turning into rubber stamping when reviewers are overwhelmed”
Almost any time I have ever thought “I’ll just printf/step through debug a problem, that will be quicker than writing the test,” I have been wrong. And importantly, by writing the test I stop some future maintainer from re-introducing the same defect in the future.
I actually give a talk on unit testing at my work (well, across three employees now), and one of the early slides contains the assertion:
> Tests don’t catch bugs.
>
> Tests assert a contract.
>
> It just so happens that correctly asserting a contract may find bugs in an implementation, and more importantly prevent new bugs from being introduced in the future.
But yes, you are limited by how “testable” the components you’re wor…
