Timeline for Should the unit tests be independent of the implementations
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 19, 2024 at 16:42 | comment | added | Ewan | @DocBrown i'm pretty sure you do understand the principle, that's why you've added the word "arbitrary" to the rule. There is no such thing as an arbitrary change, you make a change to match the specifications and the tests test that the specifications are matched. They only change when you change the specifications. Now sure, you can refactor, or fix a bug and have to change an interface or whatever, but the rule is very normal and im sure you have seen it before in various forms | |
| Feb 19, 2024 at 15:57 | comment | added | Doc Brown | @Ewan: why should arbitrary changes to a codebase (including all kind of changes to public functions and features) be possible without changing any tests? This makes no sense to me. | |
| Feb 19, 2024 at 14:14 | comment | added | Ewan | @DavidHammen im not saying "never change tests under any circumstances" im saying write your code in a way which enables you to change it without requiring a change in the tests. Which im 100000000000.9999% sure is what the referenced book means | |
| Feb 19, 2024 at 14:07 | comment | added | Ewan | if you agree that with well written code this should be possible, then you agree with the rule as phrased | |
| Feb 19, 2024 at 14:06 | comment | added | Ewan | I think you guys are being overly prescriptive in your interpretations. Let me ask this "should" you be able to change the "codebase" without having to change the tests? | |
| Feb 19, 2024 at 9:49 | comment | added | Doc Brown | Maybe there is a misunderstanding here. My critics goes against this general statement "changes to the code base". It seems you read this as "changes to implementations of certain behaviour" (and we both agree that this should not be a reason to change a test). But fact is, the OP seems to missed that "changes to the code base" means something different than "changes to implementations of certain behaviour", and that looks to me like the root cause of their confusion. | |
| Feb 18, 2024 at 22:32 | comment | added | jmoreno | @DavidHammen: which is what I said. There are occasionally reasons to keep bugs in the code, no reason ever to keep bugs in tests. | |
| Feb 18, 2024 at 21:10 | comment | added | David Hammen | @jmoreno Except in the case where the unit test authors were taken from the top 100000% of the organization's programmers and were 100000% prescient, they were merely human and were prone to make mistakes. A bug in some unit test is a bug, period. A bug is a bug, period. You don't "fix" the code to replicate the bug in the buggy test. You fix the buggy test that caused the non-buggy code base to fail. | |
| Feb 18, 2024 at 20:44 | comment | added | jmoreno | @DavidHammen: unless you are doing bug-for-bug rewrite or some similar situation where changes are disallowed, you find a bug, you fix it. Doesn’t matter whether the bug is in the app, the test or the docs. | |
| Feb 18, 2024 at 15:39 | comment | added | David Hammen | I disagree with this 10000000%. (I added a few zeros there.) Suppose the code change exposes a bug in the test code and everyone agrees that the bug is in the test code rather than the code base. Do you change the code so that it properly passes the buggy unit test, or do you change the unit test? Or suppose an external user has reported a bug or asked for a new feature, submits a proposed code change that fixes the bug / implements the feature, but does not change the test code. Everyone likes the change as-is, so the change to the code base is easy. You need a new unit test in this case. | |
| Feb 18, 2024 at 14:39 | comment | added | Ewan | thanks, yeah it's basically the same as docs answer in detail but they miss the point that rules like this are supposed to be simple all encompassing rules. If you start adding "..for behaviour" or "when test are written this way.." then you end up with a page of guidelines instead of a simple rule which forces you to do things a certain way, even if it doesn't catch every edgecase | |
| Feb 18, 2024 at 14:04 | comment | added | jmoreno | This is a great answer. I would guess the downvoter stopped reading at the 100000% and didn’t read the rest which explained that it’s correct for behavior. Might want to make that “For behavior that is 100000%”. | |
| Feb 17, 2024 at 13:46 | history | answered | Ewan | CC BY-SA 4.0 |