Well, no. Unless you consider a first draft of a small piece of code to be "production code". You add A test, then add a small incremental piece of functionality. That is not production code yet.
That was not what I said.
There is "two source codes" when you are developing a system using TDD. The one where you describes your specifications (tests if you like) and the one you deliver to the users, where the specifications will be implemented. The one you deliver is what I mean by production code in that context. I said nothing about the status of the "production" code, if was done or not. That's because I assumed that you would be at the same context level I was. I just hope that it was not an intentional straw man from you.
No, there isn't
There is no "but". Your claim is false. Period.
but there is a rule that says "very short development cycle"
This is not a rule. Neither Kent Beck or Uncle Bob accepted definitions of rules to TDD states what you said.
There is, yes, a desirable preference for very short development cycle. It is not a rule. But even if it was, what is the measure of "very short"? 1 week? 1 day? 1 hour? 1 minute? 100ms (like Gary Bernhardt)?
If you do an integration test that take 10s to run to exercise one function of the production code that you are implementing, this would be fast or slow, short or long?
It depends on the referential. If to do the same test you need to open a browser, fill up dozen fields, select the context you are trying to get right and click in a submit button, maybe it cost you 50s or more. So 10s seems really fast and short in this case, right?
And if your whole suite takes 7 minutes to run, it seems pretty bad right? But how much time would you waist doing it manually? And what if you forget some context?
If you have 200 integration tests that takes 10 seconds to run each, it could cost you 30 minutes to run them all. Yeah, that is not "very short" time to wait to get feedback. But what if you run them in parallel, using all power of your pc, achieving a result in 15, 20s? Is it not short? Is it not acceptable?
Again, your claim that TDD without unit tests is not TDD is false. This rule doesn't exists and you are defending it without any proof or evidence.
You will also find in most literature that talks of TDD, they talk about units and if you are testing units with something more than unit tests, you're probably not writing units and you're writing something that is hard to test, hard to refactor and likely hard to reason about.
There is another problem in definitions. What is the unit definition? 1 isolated function? 2 classes operating together to achieve some business behavior? What is it?
Some people are more or less restrictive than others in this matter. The Uncle Bob itself is one that had said a while ago that if you need to exercise a behavior that call the db, this is your unit in that context, making it a unit test.
I disagree with him and consider this one being an integration test, but I understood his point. In that context the minimum unit to exercise the behavior involved a call to DB and that was the Unit under test.
For me, an unit test does not do IO, DB, Internet. Which makes it very fast. But in nowhere was stated that unit test is the only way to TDD.
Given that you are conflating terms such as "production code", "unit" and expecting every action to be excluded unless explicitly defined
I conflated nothing. Probably I've explained myself poorly (which I think was the case). But there's another possibility, given your tone in the next quotation, that you just built a very big and strong straw man and now is fighting it to show the great warrior you are (if this is the case, I'll stop. Don't have time for ego trip).
Ah, now you are trying to educate me by providing resources, cool:
Nah, this was not my intention. As I wasn't able to write a longer answer at that moment I didn't want to leave my answer without elements showing the point I was making. The resources was just to enrich our discussion not a weapon to hurt your ego.
So looks like you just googled "TDD articles"
Not man. I was saying that TDD is not about tests. This reference, of Kent Beck, shows the man himself stating the same thing and explaining why, thing that I couldn't do at that time, the important thing here is that the reference explain WHY I said TDD is not about tests (again it was not a weapon to hurt your feelings). "All your testing gurus are sharpening your knives..." (something like that, I am quoting from memory).
As for this article by a relatively nobody, which says he doesn't believe in units; take a look at the adoption in the industry of this technique. It's close to zero.
I don't know if you understood what he meant. But I will assume that you did. I'll address the "relatively nobody" and "close to zero (adoption)" pieces.
Do you know the market share of the ruby made systems? Do you know a tool called RSpec? Do you know the market share of RSpec in the Ruby community? I don't know too. But, with some google searches we can suppose that is an important number and very away from zero, don't we?
Do you know Javascript? Have you ever heard about Jasmine.js? Mocha? Chai? Jest? Yeah. All of them was influenced by RSpec, which was influenced by this relatively nobody guy.
What about BDD, have you heard about it? Yeah, this guy was one of its "creators".
Some TDD tests aren’t small. Some TDD tests look more like integration or acceptance tests. There really aren’t any rules in that regard. So perhaps the best name of all is simply:TDD tests. Why? Because TDD tests are unique.
We use the term “unit” test to describe the tests we write while using TDD. But that name is unfortunate because it has no good definition. We don’t know what a unit really is.
The tests we write in TDD are written by programmers and for programmers.
There is no rule that says that unit tests can’t touch the database. Of course they can. One should be very careful, however, to avoid touching the database when the database is not relevant to the test.
Cheers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That was not what I said.
There is "two source codes" when you are developing a system using TDD. The one where you describes your specifications (tests if you like) and the one you deliver to the users, where the specifications will be implemented. The one you deliver is what I mean by production code in that context. I said nothing about the status of the "production" code, if was done or not. That's because I assumed that you would be at the same context level I was. I just hope that it was not an intentional straw man from you.
There is no "but". Your claim is false. Period.
This is not a rule. Neither Kent Beck or Uncle Bob accepted definitions of rules to TDD states what you said.
There is, yes, a desirable preference for very short development cycle. It is not a rule. But even if it was, what is the measure of "very short"? 1 week? 1 day? 1 hour? 1 minute? 100ms (like Gary Bernhardt)?
If you do an integration test that take 10s to run to exercise one function of the production code that you are implementing, this would be fast or slow, short or long?
It depends on the referential. If to do the same test you need to open a browser, fill up dozen fields, select the context you are trying to get right and click in a submit button, maybe it cost you 50s or more. So 10s seems really fast and short in this case, right?
And if your whole suite takes 7 minutes to run, it seems pretty bad right? But how much time would you waist doing it manually? And what if you forget some context?
If you have 200 integration tests that takes 10 seconds to run each, it could cost you 30 minutes to run them all. Yeah, that is not "very short" time to wait to get feedback. But what if you run them in parallel, using all power of your pc, achieving a result in 15, 20s? Is it not short? Is it not acceptable?
Again, your claim that TDD without unit tests is not TDD is false. This rule doesn't exists and you are defending it without any proof or evidence.
There is another problem in definitions. What is the unit definition? 1 isolated function? 2 classes operating together to achieve some business behavior? What is it?
Some people are more or less restrictive than others in this matter. The Uncle Bob itself is one that had said a while ago that if you need to exercise a behavior that call the db, this is your unit in that context, making it a unit test.
I disagree with him and consider this one being an integration test, but I understood his point. In that context the minimum unit to exercise the behavior involved a call to DB and that was the Unit under test.
For me, an unit test does not do IO, DB, Internet. Which makes it very fast. But in nowhere was stated that unit test is the only way to TDD.
I conflated nothing. Probably I've explained myself poorly (which I think was the case). But there's another possibility, given your tone in the next quotation, that you just built a very big and strong straw man and now is fighting it to show the great warrior you are (if this is the case, I'll stop. Don't have time for ego trip).
Nah, this was not my intention. As I wasn't able to write a longer answer at that moment I didn't want to leave my answer without elements showing the point I was making. The resources was just to enrich our discussion not a weapon to hurt your ego.
Not man. I was saying that TDD is not about tests. This reference, of Kent Beck, shows the man himself stating the same thing and explaining why, thing that I couldn't do at that time, the important thing here is that the reference explain WHY I said TDD is not about tests (again it was not a weapon to hurt your feelings). "All your testing gurus are sharpening your knives..." (something like that, I am quoting from memory).
I don't know if you understood what he meant. But I will assume that you did. I'll address the "relatively nobody" and "close to zero (adoption)" pieces.
Do you know the market share of the ruby made systems? Do you know a tool called RSpec? Do you know the market share of RSpec in the Ruby community? I don't know too. But, with some google searches we can suppose that is an important number and very away from zero, don't we?
Do you know Javascript? Have you ever heard about Jasmine.js? Mocha? Chai? Jest? Yeah. All of them was influenced by RSpec, which was influenced by this relatively nobody guy.
What about BDD, have you heard about it? Yeah, this guy was one of its "creators".
dannorth.net/introducing-bdd/
Don't know if your ego will have problem with this resource too. I am just backing up my points. Sorry if it bother you.
And before you come with the 3 rules by uncle bob with the word "unit tests" in it, take a look at this:
twitter.com/unclebobmartin/status/...
twitter.com/unclebobmartin/status/...
twitter.com/unclebobmartin/status/...
twitter.com/unclebobmartin/status/...
Cheers.