I'm not cofusing anything. I never mentioned any framework either.
You can do TDD with zero unit tests and it still is TDD. TDD is the practice of write your behavior spec before the production code. There's no rule or consensus anywhere stating that if you're not using unit tests then it is not TDD.
I have not the time now to address your others arguments but I'll leave you with the names of two good articles, one from IEEE, Kent Beck, 2001: "Aim, Fire" and the other from Dave Astels, 2005: "A New Look at Test Driven Development".
TDD is the practice of write your behavior spec before the production code
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. If you write ALL your tests first, then all your "production code" then it is not TDD because there's a 99.99% change you have messed up many requirements/specs (as you can't know all in advance, hence the origin of incremental development) and you have slowed yourself down.
There's no rule or consensus anywhere stating that if you're not using unit tests then it is not TDD.
No, there isn't but there is a rule that says "very short development cycle" and if you want to remove the "very" and make it integration tests, you've started to lose focus on TDD, if you also remove "short" by making it system tests then all you have is "development cycle" and it's arguably no longer TDD.
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.
Given that you are conflating terms such as "production code", "unit" and expecting every action to be excluded unless explicitly defined
Ah, now you are trying to educate me by providing resources, cool:
IEEE, Kent Beck, 2001: "Aim, Fire"
I'm not sure which of your assertions you think this supports given that it is a three page article in which he uses unit tests and describes TDD as "test first". So looks like you just googled "TDD articles" and posted it thinking you were right and it would just support you as a side effect of that.
Dave Astels, 2005: "A New Look at Test Driven Development"
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. Whereas entire systems, companies and frameworks have popped up before and since around units. So Dave might not like it but the industry doesn't care.
Interestingly, all of his recommended TDD books are in stark contrast to his views on units. So...pinch of salt.
They have reasons to say what they said.
The first one said nothing, second one...is clearly confused.
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.
I'm not cofusing anything. I never mentioned any framework either.
You can do TDD with zero unit tests and it still is TDD. TDD is the practice of write your behavior spec before the production code. There's no rule or consensus anywhere stating that if you're not using unit tests then it is not TDD.
I have not the time now to address your others arguments but I'll leave you with the names of two good articles, one from IEEE, Kent Beck, 2001: "Aim, Fire" and the other from Dave Astels, 2005: "A New Look at Test Driven Development".
They have reasons to say what they said.
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. If you write ALL your tests first, then all your "production code" then it is not TDD because there's a 99.99% change you have messed up many requirements/specs (as you can't know all in advance, hence the origin of incremental development) and you have slowed yourself down.
No, there isn't but there is a rule that says "very short development cycle" and if you want to remove the "very" and make it integration tests, you've started to lose focus on TDD, if you also remove "short" by making it system tests then all you have is "development cycle" and it's arguably no longer TDD.
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.
Given that you are conflating terms such as "production code", "unit" and expecting every action to be excluded unless explicitly defined
Ah, now you are trying to educate me by providing resources, cool:
IEEE, Kent Beck, 2001: "Aim, Fire"
I'm not sure which of your assertions you think this supports given that it is a three page article in which he uses unit tests and describes TDD as "test first". So looks like you just googled "TDD articles" and posted it thinking you were right and it would just support you as a side effect of that.
Dave Astels, 2005: "A New Look at Test Driven Development"
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. Whereas entire systems, companies and frameworks have popped up before and since around units. So Dave might not like it but the industry doesn't care.
Interestingly, all of his recommended TDD books are in stark contrast to his views on units. So...pinch of salt.
The first one said nothing, second one...is clearly confused.
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.