re: Getting Started with Test Driven Development VIEW POST

FULL DISCUSSION
 

Firstly, TDD is universally misunderstood.

creating software by writing tests before writing code.

This is the most frequent misunderstanding. TDD is not writing tests then writing functionality. It is writing a test for the absolute simplest case, fixing that test then adding a test case. Therefore, testing is done alongside your code. I would have maybe accepted "creating software by writing a test before writing code." but "tests", no.

Take the example that you want to write a program that parses roman numerals.

  • You write the test myParser.parse("I") == 1
  • You write a RomanNumeralParser class
  • You add a method to parse
  • You write the functionality "if string.equals("I") return 1"

It's also important to note (as without it, it's not TDD) that Test Driven Development requires that

  • Your tests are unit tests
    • They are quick and standalone
  • You write the absolute minimal code to satisfy requirements
  • You refactor as you go

People who are against TDD have usually been exposed to it in the wrong way. It should be done correctly and strictly for a period of time, once it shows you how many assumptions you make in programming you then loosen how strictly you follow TDD. It's not a methodology to be followed, it's a practice to show you how to test properly and the benefits of fast, contained, independent unit tests.

 

TDD doesn't require your spec to be an unit test. It is desirable to have the majority of your specs as unit, but it is not a commandament.

"it's a practice to show you how to test properly and the benefits of fast, contained, independent unit tests."

No. It is to help you analise requirements and design your software to meet those requirements. It is a development tool, it is not a test tool and it is not for tests. It helps with confidence to change code, refactoring, adding, removing, code. It helps you discover simple implementations to solve the current problem (test).

The first 2 steps, add a failing spec and making it pass is to build confidence, the third one, refactor, is to improve design applying best practices, patterns and so on, with the confidence that your changes is not breaking any desired and already existent behavior.

Test is another realm with tons of others methodology and practices that should not be confused with TDD. Ever.

 

You may consider just writing a full article on TDD, @danielfoxp2 . It'd get more views, and more robust feedback, than just the comments section of another article. Just click WRITE A POST in the upper-right here on DEV.

(Although, to reiterate from earlier; you haven't posted anything that's news to me about this, yet TDD still doesn't work for me. If you explained it, it might make better sense and work for someone else, though!)

Thanks... I'm creating courage to start it =).

 

TDD doesn't require your spec to be an unit test.

No but 99% will be because rapid development with system tests is hard and in many cases impossible. Rapid development with integration tests is just hard. The more components involved, the slower development gets and TDD is about fast development cycle.
Who said it was a "commandment"? It's common sense. If the majority of (and preferably all) your TDD is not unit tests, you are not doing TDD.

Test Driven Development [...] "is not for tests".

"Test[s] [...] should not be confused with Test Driven Development.

Classic quotes!

It helps with confidence to change code, refactoring, adding, removing, code

Those are side effects of testing properly and having good test coverage. If you do TDD then remove the tests ALL of these benefits go away. So how you can say TDD is not about tests when without them, it's not TDD is beyond me.

You are confusing test frameworks and QA with code tests and somehow conflating them with TDD.

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.

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".

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/...

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.

twitter.com/unclebobmartin/status/...

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.

twitter.com/unclebobmartin/status/...

DAO tests are unit tests.

twitter.com/unclebobmartin/status/...

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.

code of conduct - report abuse