4 ms·

When fixing bug it makes sense. But when writing new code?

Jtsummers 4y ago
It does make sense with new code, yes. Whether for all code or not, or whether unit tests or integration or end to end tests though is up to your judgement. No one but you, who knows your system and your capabilities and knowledge, can decide for you. Only fools expect a technique to replace thinking. I assume you're not a fool. For new code, the reason it makes sense is that your system is bugged. It does not do what it's intended to do yet because you haven't written the code to do it (or altered the existing code to add the new capability). So the test detects the difference between the current state of the system and the desired state, and then you implement the code and now the test detects that you have achieved your desired state (at least as far as the test can detect, you could still have other issues).
garethrowlands 4y ago
Yes, new code too. If the test doesn't fail at first, you have a different problem than you thought.
mpweiher 4y ago
> [R->G] But when writing new code? Absolutely, and most prominently when writing new code. The red-green transition is absolutely essential for new code. You should not write any production code except to make a red test green. Think of the tests as the specification of your system. If all tests are green, your system meets the specification. Thus there is no need to write production code. So in order to make the system do something new, you need to first change the specification. So you add a test. When you add this test, it will almost certainly fail. After all, you haven't written the code to implement the feature. Then you make the test green, and now the system once again matches the (now updated) specification. Commit/Refactor/Commit. Having the test that is red also validates your tests. If your tests are always green, how do you know that you're actually testing something? In fact, it sometimes happens that you write a test that you think should be red, because you haven't implemented the feature yet, but then it starts of as green. Meaning you inadvertently already built the feature. This can be very confusing... :-)
lolinder 4y ago
The red step is how you test your test: if you don't get red at first, your test is wrong. If I only see green for a given test, I have no way of knowing if it is asserting anything at all, much less if it's testing what I thought it was.
jfengel 4y ago
There is a saying that coding is debugging a blank piece of paper. ("Piece of paper" tells you how old this saying is.) "New code" just means "I want a program to do a thing, and it doesn't do it yet. That's a bug." The difference between "bug" and "new feature" is more a matter of perspective than actual development effort.
- smaudet 4y ago
  Bugs are features which were not expected.
lowbloodsugar 4y ago
If you write the code first and then the test, how do you know your test works? You've only ever run it against working code. Like if there was a virulent disease for which there was a 100% cure, but you can't get the cure unless you test positive for the disease. I give you a test and say "Yep, test says you are healthy". Ok. What if the test always says people are healthy? "Have you ever tested an unhealthy person and the test detected that they were unhealthy?" "Oh, no, we've done this test a thousand times and it always says people are healthy!" You write the test first, because your code does not yet have the feature that you are testing. Your current code is a perfect test for the test. Anyone who has done TDD for even a short amount of time has written a test that should have failed but instead it passed. Sometimes the was just a simple error in the test. You fix the test so it can detect what you are looking for (i.e. the test now fails). Other times a fundamental misconception was discovered that blows everyone's mind.
- spc476 4y ago
  I'm replying to this one, but really, it applies to each of the replies to tester756. I want to say you all are insane, but I'm wondering if it's just that I do a different type of programming, or that the language I'm using doesn't lend itself well to TDD. Example, I have a function, in C [1], that runs another program and returns true or false. The prototype is: extern bool run_hook(char const *tag,char const **argv); // [2] tag is informational; argv is an array where argv[0] is the program name, the rest are arguments. Okay, how would you write a test first for this? You literally can't, because the function has to exist to even link it to a test program. Please tell me, because otherwise, this has to be the most insane way to write software I've come across. [1] LEGACY CODE! [2] I go more into testing this function here: <https://boston.conman.org/2022/12/21.1 https://boston.conman.org/2022/12/21.1>. The comments I've received about that have been interesting, including "that's not a unit test." WTF?
  - Jtsummers 4y ago
    What's the problem here? You would write the test (if you're doing TDD, which you wouldn't always do anyways because you recognize it's a tool and not all tools are appropriate for all situations). The test would fail because it doesn't compile, so you make it compile. Not compiling counts as a failed test, even fools get that. Unless of course you're only working no trivial programs (based on your write up, not the case) or an absolute genius you must have at some point or another encountered a failed compilation and used that as feedback to change the code. This is no different.

It does make sense with new code, yes. Whether for all code or not, or whether unit tests or integration or end to end tests though is up to your judgement. No one but you, who knows your system and your capabilities and knowledge, can decide for you. Only fools expect a technique to replace thinking. I assume you're not a fool. For new code, the reason it makes sense is that your system is bugged. It does not do what it's intended to do yet because you haven't written the code to do it (or altered the existing code to add the new capability). So the test detects the difference between the current state of the system and the desired state, and then you implement the code and now the test detects that you have achieved your desired state (at least as far as the test can detect, you could still have other issues).

garethrowlands 4y ago

Yes, new code too. If the test doesn't fail at first, you have a different problem than you thought.

mpweiher 4y ago

> [R->G] But when writing new code? Absolutely, and most prominently when writing new code. The red-green transition is absolutely essential for new code. You should not write any production code except to make a red test green. Think of the tests as the specification of your system. If all tests are green, your system meets the specification. Thus there is no need to write production code. So in order to make the system do something new, you need to first change the specification. So you add a test. When you add this test, it will almost certainly fail. After all, you haven't written the code to implement the feature. Then you make the test green, and now the system once again matches the (now updated) specification. Commit/Refactor/Commit. Having the test that is red also validates your tests. If your tests are always green, how do you know that you're actually testing something? In fact, it sometimes happens that you write a test that you think should be red, because you haven't implemented the feature yet, but then it starts of as green. Meaning you inadvertently already built the feature. This can be very confusing... :-)

lolinder 4y ago

The red step is how you test your test: if you don't get red at first, your test is wrong. If I only see green for a given test, I have no way of knowing if it is asserting anything at all, much less if it's testing what I thought it was.

jfengel 4y ago

There is a saying that coding is debugging a blank piece of paper. ("Piece of paper" tells you how old this saying is.) "New code" just means "I want a program to do a thing, and it doesn't do it yet. That's a bug." The difference between "bug" and "new feature" is more a matter of perspective than actual development effort.

smaudet 4y ago
Bugs are features which were not expected.

lowbloodsugar 4y ago

If you write the code first and then the test, how do you know your test works? You've only ever run it against working code. Like if there was a virulent disease for which there was a 100% cure, but you can't get the cure unless you test positive for the disease. I give you a test and say "Yep, test says you are healthy". Ok. What if the test always says people are healthy? "Have you ever tested an unhealthy person and the test detected that they were unhealthy?" "Oh, no, we've done this test a thousand times and it always says people are healthy!" You write the test first, because your code does not yet have the feature that you are testing. Your current code is a perfect test for the test. Anyone who has done TDD for even a short amount of time has written a test that should have failed but instead it passed. Sometimes the was just a simple error in the test. You fix the test so it can detect what you are looking for (i.e. the test now fails). Other times a fundamental misconception was discovered that blows everyone's mind.

spc476 4y ago
I'm replying to this one, but really, it applies to each of the replies to tester756. I want to say you all are insane, but I'm wondering if it's just that I do a different type of programming, or that the language I'm using doesn't lend itself well to TDD. Example, I have a function, in C [1], that runs another program and returns true or false. The prototype is: extern bool run_hook(char const *tag,char const **argv); // [2] tag is informational; argv is an array where argv[0] is the program name, the rest are arguments. Okay, how would you write a test first for this? You literally can't, because the function has to exist to even link it to a test program. Please tell me, because otherwise, this has to be the most insane way to write software I've come across. [1] LEGACY CODE! [2] I go more into testing this function here: <https://boston.conman.org/2022/12/21.1 https://boston.conman.org/2022/12/21.1>. The comments I've received about that have been interesting, including "that's not a unit test." WTF?
- Jtsummers 4y ago
  What's the problem here? You would write the test (if you're doing TDD, which you wouldn't always do anyways because you recognize it's a tool and not all tools are appropriate for all situations). The test would fail because it doesn't compile, so you make it compile. Not compiling counts as a failed test, even fools get that. Unless of course you're only working no trivial programs (based on your write up, not the case) or an absolute genius you must have at some point or another encountered a failed compilation and used that as feedback to change the code. This is no different.