You write tests for functionality before you write the functionality.
You code the functionality so the tests pass.
Then, and only then, the test becomes a regression test and is enabled in your CI automation.
If the test ever breaks again the merge is blocked.
If you only write tests after you’ve written the code then the test will test that the code does what the code does. Your brain is already polluted and you’re not capable of writing a good test.
Having tests that fail is fine, as long as they’re not part of your regression tests.
You write tests for functionality before you write the functionality.
You code the functionality so the tests pass.
Then, and only then, the test becomes a regression test and is enabled in your CI automation.
If the test ever breaks again the merge is blocked.
I disagree. Merging should be blocked on any failing test. No commit should be merged to master with a failing test. If you want to write tests first, then do that on a feature branch, but squash the commits properly before merging. Or add them as disabled first and enable after the feature is implemented. The enabled tests must always pass on every commit on master.
You’re both right. You’re both wrong.
If you only write tests after you’ve written the code then the test will test that the code does what the code does. Your brain is already polluted and you’re not capable of writing a good test.
Having tests that fail is fine, as long as they’re not part of your regression tests.
I disagree. Merging should be blocked on any failing test. No commit should be merged to master with a failing test. If you want to write tests first, then do that on a feature branch, but squash the commits properly before merging. Or add them as disabled first and enable after the feature is implemented. The enabled tests must always pass on every commit on master.
So I can never commit a test without also implementing the functionality?
That’s madness.
You can, but not on master.