Re:Our journey to type checking 4M lines of Python
by jdm2212 on Sunday September 08, 2019 @02:12AM
(#20908898)
This was a few years ago. The chaos was partly because of a lack of ownership: one team owned inputs, the other owned outputs, and there wasn't a clear spec. The whole pipeline was pretty experimental and people made up new semantics as needed, and were happy to change failing tests (or just added untested codepaths behind boolean flags in existing functions). Compile-time type checking would've enforced a greater degree of rigor about modeling what was happening and made clear all the ways existing code could be affected.
People can change unit tests. The benefit of this, is it's a kind of documentation. People can see the tests and know how it _should_ work, or they can not read them and if they create errors, they'll find out the hard way. Unit tests don't make a specification static, but they do reduce chaos.