Devs make mistakes. We want to put up guardrails so mistakes don’t hurt us so much.
Please don’t deliberately line the guardrails with barbed wire.
You work somewhere where the tests don’t always fail???
Ha, losers - tests can’t fail if you don’t have any tests.
Why write tests when you should be writing more features the business needs now but will never use?
a bug? No problem we will just fix it in the next release. loop for eternity.
Have you tried rerunning them all day until they pass? 😄
Would you look at that - the pipeline is green now! Quick everybody, merge your stuff while it’s stable (/s) (sadly a true story tho)
You just guessed my job lol
The real problem is merging before waiting for that one slow CI pipeline to complete
gitlab has a feature where you can set it to auto-merge when and if the CI completes successfully
Imagine having unit tests, my company could never
deleted by creator
Sure, but do you want to risk catastrophy as a way to filter out bad developers?
deleted by creator
Bro just crash the CI because the linter found an extra space bro trust me bro this is important. Also Unit tests are optional.
…it’s okay on rare and understood cases. (Why else would you be able to merge if it’s failing.)
“You don’t have the hiring and firing power.”
– Kitty, Arrested Development
deleted by creator
If you only write tests for things that won’t fail, you’re doing it wrong. Are you anticipating some other feature coming soon? Write a failing test for it. Did you find untested code that might run soon with a little work? Write a test for it. Did a nonessential feature break while adding an essential feature, let the test fail and fix it later.
Eww, no. You’re doing tests wrong. The point of tests is to understand whether changes to the code (or dependencies) break any functionality. If you have failing tests, it makes this task very difficult and time consuming for people who need it most, i.e. people new to the project. “Is this test failing because of something I’ve done? <half an hour of debugging later> Oh, it was broken before my changes too!”. If you insist on adding broken tests, mark them as “expected to fail” at least, so that they don’t affect the overall test suite result (and when someone fixes the functionality they have to un-mark them as expected to fail), and the checkmark is green. You should never merge PRs/MRs which fail any tests - it is an extremely bad habit and forms a bad culture in your project.
There are two different things mentioned here, which I feel I need to clarify:
First, what you said about merging / creating a PR with broken tests. Absolutely you shouldn’t do that, because you should only merge once the feature is finished. If a test doesn’t work, then either it’s testing for the wrong aspect and should be rewritten, or the functionality doesn’t work 100% yet, so the feature isn’t ready to get merged. Even if you’re waiting for some other feature to get ready, because you need to integrate it or something, you’re still waiting, so the feature isn’t ready.
At the same time, the OP’s point about tests being supposed to fail at first isn’t too far off the mark either, because that’s precisely how TDD works. If you’re applying that philosophy (which I personally condone), then that’s exactly what you do: Write the test first, checking for expected behaviour (which is taken from the specification), which will obviously fail, and only then write the code implementing that behaviour.
But, even then, that failing test should be contained to e.g. the feature branch you’re working on, never going in a PR while it’s still failing.
Once that feature has been merged, then yes, the test should never fail again, because that indicates a new change having sabotaged some area of that feature. Even if the new feature is considered “essential” or “high priority” while the old feature is not, ignoring the failure is one of the easiest ways to build up technical debt, so you should damn well fix that now.
I concede that on a feature branch, before a PR is made, it’s ok to have some failing tests, as long as the only tests failing are related to that feature. You should squash those commits after the feature is complete so that no commit has a failing test once it’s on master.
(I’m also a fan of TDD, although for me it means Type-Driven Development, but I digress…)
