7 ms·
There are times where it is reasonable, especially for bug fixes where there is a test to explicitly check that the bug is fixed. In that case, I might check ou
by nabbed 1y ago
There are times where it is reasonable, especially for bug fixes where there is a test to explicitly check that the bug is fixed. In that case, I might check out the code, revert the fix, and ensure that the test fails. There have been a few times I did that and the test still succeeded, so I can confirm that the test is not testing the right thing (in a very mature project, complexity or test settings can obscure what your test is actually doing, especially if it is an E2E test).
- hexbin010 1y agoYup, same here
- esprehn 1y agoThat can be an automated CI check that runs the new tests with the non-test files reverted though.
- pavel_lishin 1y agoIt can be! And maybe even should be. But I've never seen it. A great idea, though; when we finally get automated testing in CI, I'll certainly suggest it :)
- Scarblac 1y agoThat wouldn't necessarily compile though, eg if the fix involved changing a function signature or adding new functions.
- globular-toast 1y agoI have done a similar thing. I teach juniors to follow a strict test-driven development style when handling bug fixes. Write the missing, and failing, test first, then make the tests pass. (I also recommend using this approach for everything). But you can't tell if they've actually done this. It makes me think that this should be automated. Seems fairly straightforward to do in test frameworks that keep the tests in separate files. Bit harder if they're in the same files, like Rust.