4 ms·
Sounds interesting. Could you elaborate, I don't quite understand it. You test for regression errors before commit? But why commit with known regression errors?
by theyinwhy 3y ago
Sounds interesting. Could you elaborate, I don't quite understand it. You test for regression errors before commit? But why commit with known regression errors?
- pnt12 3y agoMaybe they test (with code or manually) different commits and then point out which one introduced the problem in the ticket system. Could be useful but parent mentions a megacorp, so maybe it's just some bureaucracy or ball-breaking.
- spudtrooper 3y agoAs a previous comment said, this sounds like a generalization of regression testing. This article seems to focus on the small scale and omits a couple points relevant to larger scale systems: - data dependencies cause regressions, so you. need some way to factor this in - production changes cause regressions - debugging at the source code level can be laborious past a certain point The way I approached doing this at another (maybe same) T$ compnay was tooling that could take anything observable -- e.g. logs, program traces, signals from services, service definitions, data, stack traces from debuggers for side-by-side running -- convert it to a normal form (e.g. protobuf or JSON) and then diff that to look for regressions.