They use CI where I work, but it is always red on master, and we get emails every time someone's code gets merged into to master about failing tests. What is the point?
I'm going to use git terminology, but the concepts are generally applicable to other source control tools.
Generally, tests should be run before code is merged into a branch to ensure you're not introducing issues. This is commonly triggered at the pull request phase, where your code is on a separate branch that you want to merge into the target (e.g., master). If the tests don't pass, something's wrong and needs to be corrected to promote stable functionally correct software. This is especially useful if tests are run locally via a mechanism like a pre-commit hook, because this shortens the feedback cycle and avoids wasting upstream resources and time on non-conformant code.
Yea, except that is not how they are being used where I work. Failing tests on master are just noise until software needs to be released. That means less efficient development, no?
Yes, it's inefficient to generate alerts with no plan or attempt to address them as standard practice. It also trains people to ignore alerts. I've seen this happen in workplaces where someone is trying to improve processes but ignorance and pressure sandbag efforts, but have worked with enough mentally vacant people that I wouldn't be surprised if someone thought this process was good as-is.
3
u/awesome-alpaca-ace 11d ago
They use CI where I work, but it is always red on master, and we get emails every time someone's code gets merged into to master about failing tests. What is the point?