Timeline for TDD and Version Control
Current License: CC BY-SA 3.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 18, 2021 at 7:00 | comment | added | BЈовић | TDD tells to write a failing test, fix the bug, then check in the changes. You don't check in failing tests. | |
| Oct 16, 2021 at 5:04 | comment | added | Kaz | @BЈовић One argument is this: failing tests choke up the continuous integration pipeline, preventing people from getting new builds out into testers' hands. If a failing test is committed for a minor bug which isn't affecting anyone, then that bug's priority thereby effectively escalates. Now it is affecting everyone. | |
| Oct 15, 2021 at 22:15 | comment | added | Kaz | @BЈовић In this hypothetical (but entirely realistic, everyday) situation, a bug has been found in a program whose test suite is all green, and a failing test can be easily added which matches this bug. Can you make some sort of convincing argument that a test should not be written and checked in? If we know the program has a bug, what value is there in the test suite being green? Emotional comfort? But how can there be even emotional comfort when you know about an untested bug? | |
| Oct 15, 2021 at 7:13 | comment | added | BЈовић | @Kaz That is also possible. Some things are not possible to test. | |
| Oct 14, 2021 at 15:27 | comment | added | Kaz | @BЈовић the concern is that this fails to provide detailed evidence in that anything was fixed, or that the test is targetting something relevant. Maybe the new test that was committed would still be green without the accompanying fix. | |
| Oct 14, 2021 at 14:57 | comment | added | BЈовић | @Kaz No. 1. implement test 2. fix the bug. All in one commit, if possible. When sending code to repository, all tests should be green. Tests can not cover 100%, so if all green, that means that that code is most likely fine. | |
| Oct 12, 2021 at 19:05 | comment | added | Kaz | How about slightly outside of the context of TDD? Suppose a bug is discovered in code that is already released. Should you commit a failing test which covers the bug, and then fix the bug in another commit? Or is that also off the table? What's the use of all tests being green when we know that the trunk has a bug? Just to feel good? | |
| May 16, 2018 at 16:46 | comment | added | Marnen Laibow-Koser | About failing tests: when I'm developing new code, I never commit a test till it passes. However, when I'm fixing a bug, my first step is to write a test that proves the bug exists, and I often do commit that test as soon as I write it. (The application was already committed in a broken state; I'm just adding a test that shows that.) Of course, the branch with the bugfix doesn't get merged in till it's no longer broken. | |
| Jun 17, 2013 at 17:38 | comment | added | radarbob | @Code-Guru. Yes, "Don't break the build" applies to DVCS. You can screw yourself all you want (it's inevitable); but never give your team mates code that will not compile. | |
| Jun 17, 2013 at 15:04 | comment | added | Pete | Even if you aren't pushing, making a commit with a broken state will make "git bisect" operations much harder, as you will have to wade through tons of failing revisions. At least do a rebase and squash the failing commit with the successful implementation before pushing. | |
| S Jun 17, 2013 at 11:49 | history | suggested | user82793 | CC BY-SA 3.0 | corrected grammar |
| Jun 17, 2013 at 11:47 | review | Suggested edits | |||
| S Jun 17, 2013 at 11:49 | |||||
| Jun 17, 2013 at 8:05 | comment | added | Bart van Ingen Schenau | @Code-Guru: For a DVCS, that rules should be: "Don't commit broken code to a branch that others regularly pull from". If others don't pull from your local repo, then that can be in any state you can live with. | |
| Jun 17, 2013 at 7:29 | comment | added | BЈовић | @mouviciel Yes, that's the idea, but other people should not see red test. Checking in a test that is red means you are very sloppy. And under check-in, I mean pushing changes so other developers get them. | |
| Jun 17, 2013 at 7:27 | history | edited | BЈовић | CC BY-SA 3.0 | added 495 characters in body |
| Jun 17, 2013 at 7:06 | comment | added | mouviciel | @BЈовић - TDD tells that a test must be red before green. If the test is never red, that means either that the test is not relevant or that the feature is already in the code. | |
| Jun 17, 2013 at 6:24 | comment | added | BЈовић | @mouviciel No, it does not make sense, because you are going check in a red test (failing test), and TDD tells that all tests should be green (pass). | |
| Jun 16, 2013 at 21:33 | comment | added | mouviciel | No, do not commit failing test. But one of the points of TDD is precisely to make a failing test before coding. So commiting a failing test makes sense. | |
| Jun 16, 2013 at 20:41 | comment | added | Code-Guru | @radarbob Does this apply even for a DVCS where there is a distinction between committing and pushing? I can imagine a situation where I make several commits to my local git repo where at the final commit the build isn't broken but at any of the interim commits it might be. | |
| Jun 16, 2013 at 20:21 | comment | added | radarbob | The first law of source control is "Do not break the build". In other words "..committing something that doesn't even compile makes no sense"; in a team environment you just caused work to stop for everyone. | |
| Jun 16, 2013 at 19:51 | comment | added | Matsemann | I think committing is fine after writing a test, just don't push it till you're done. | |
| Jun 16, 2013 at 19:48 | comment | added | Mateusz | "and will certainly make angry people working on the same project if" - someone is living in SVN world use GIT and you will not make anyone angry | |
| Jun 16, 2013 at 19:26 | history | answered | BЈовић | CC BY-SA 3.0 |