On 6/20/2013 2:49 AM, Jacob Carlborg wrote:
> On 2013-06-19 23:54, Walter Bright wrote:
>
>> TDD strikes me as an ad-hoc way of constructing code, and is a poor
>> substitute for thinking about the problem as a whole. For example, I
>> don't really see how getting a square root function to pass its test
>> cases is going to lead one to implementing one of the classic algorithms
>> for computing square roots. I don't see how TDD for a compiler will lead
>> one to rediscover what is known about the best way to organize the logic
>> of a compiler.
>>
>> TDD is "curve fitting" which is what one does when one has no
>> understanding.
>
> I have not watch the video(s) but I think you completely failed to understand
> what TDD is about. This is how I think about TDD:
>
> 1. You have a problem to solve
> 2. You think about how to solve the problem and how a design can look like
> 3. You come up with a design
> 4. Write a test according to the design
> 5. Write the implementation
> 6. Run the test to see that the implementation matches your design
> 7. Repeat 2-6 until satisfied

Uncle Bob's 3 laws of TDD:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.

2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Your procedure is much more reasonable, but I suspect the latter is more "principled" TDD, although it is fairly absurd as it implies a complete lack of understanding or design, and was what I was referring to.

And, btw, your lexer example of TDD is exactly what I think is wrong with TDD.

On 06/19/2013 11:54 PM, Walter Bright wrote:
> On 6/19/2013 4:01 AM, Szymon Gatner wrote:
>> This is not strictly D related but I am very curious about D's
>> community opinion
>> on the points made by non other than Jim Coplien here:
>
>
> TDD strikes me as an ad-hoc way of constructing code, and is a poor
> substitute for thinking about the problem as a whole. For example, I
> don't really see how getting a square root function to pass its test
> cases is going to lead one to implementing one of the classic algorithms
> for computing square roots. I don't see how TDD for a compiler will lead
> one to rediscover what is known about the best way to organize the logic
> of a compiler.
>
> TDD is "curve fitting" which is what one does when one has no
> understanding.

Concrete example in DMD: 'forward reference error'.

>
> D's support of unit testing is not an endorsement of TDD.

On 2013-06-20 20:14, Sean Kelly wrote:

> And this is why the waterfall model (which TDD seems to encourage) tends to be problematic.

You don't write all the test at once and then all the implementations at once. Write tests for one function first, then implement it. Then move to the next function.

Also, tests are not written in stone. They should evolve and change just as much as the rest of the code.

-- 
/Jacob Carlborg

On 2013-06-20 16:46, Andrei Alexandrescu wrote:

> I dislike this. I've seen conference talks and such where the speakers
> present the inevitable throwaway implementation that is patently wrong
> but makes the first unittest pass. That mindset doesn't sit well with me
> at all. I don't see why I need to waste time writing tongue-in-cheek
> code that is nonsensical and will obviously be deleted next.

Yes, I agree with you. I skip that test and write the correct implementation from the beginning. That's what I wrote in the last paragraph.

-- 
/Jacob Carlborg

On 2013-06-20 20:44, Walter Bright wrote:

> Uncle Bob's 3 laws of TDD:
>
> 1. You are not allowed to write any production code unless it is to make
> a failing unit test pass.
>
> 2. You are not allowed to write any more of a unit test than is
> sufficient to fail; and compilation failures are failures.
>
> 3. You are not allowed to write any more production code than is
> sufficient to pass the one failing unit test.
>
> http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
>
> Your procedure is much more reasonable, but I suspect the latter is more
> "principled" TDD, although it is fairly absurd as it implies a complete
> lack of understanding or design, and was what I was referring to.

I don't care about Uncle Bob. I say use your common sense.

> And, btw, your lexer example of TDD is exactly what I think is wrong
> with TDD.

I never write those dummy implementation, I really don't see the point.

-- 
/Jacob Carlborg

On 6/20/2013 12:51 PM, Jacob Carlborg wrote:
> I say use your common sense.

Exactly. TDD strikes me as one of those endless attempts to substitute a rigid set of rules for thought and common sense.


> I never write those dummy implementation, I really don't see the point.

Well, it was your example :-)

On Thu, 20 Jun 2013 03:15:54 +0200
"Chris Cain" <clcain@uncg.edu> wrote:
> 
> Personally, I'm a big fan of TDD in general, but I think it's one of the most often misunderstood things in the field of programming. It's like if you ask a group of religious people to define what their deity wants from them... everyone's going to have a different response and everyone is going to claim that theirs is the "only one true way."
> 
> So, here's my "only one true way" of TDD (tongue in cheek):
> 
> [...]
> 
> Anyway, TDD isn't BS, but I do think its misused. The misusage of it is (sometimes) BS, for sure.

Very interesting and helpful explanation! I don't feel somewhat unclear about it now like I did before.

It sounds like instead of trying to come up with a better buzzword for it, they should just call it "Design Your API First". Calling it TDD or BDD or whatever is like referring to DRY as "Generalization Oriented Coding". Pointless obfuscation of meaning.

I do, however, still find that designing an API before doing any
implementation is frequently premature ("Premature design", I guess you
could call it. Counterpart to "premature optimization".) Granted, I
certainly agree it's often good to give at least some up-front thought
to API and overall architectural design. But in my experience, the
amount of up-front design is something that needs to be judged on
a case-by-case basis, and the "right amount" for a given task will
likely be different for every programmer.

I've found that trying to do a detailed API design up-front is usually (not always, but frequently) a very bad ROI. It can easily end up taking a fair amount of effort (since there's so many unknowns at that point), and then most of it ends up needing to change anyway (since it's based on so many unknowns), which renders anything more than a rough up-front analysis wasted effort.

What usually works much better for me is to first get something *working*, and *then* look at the API from a user's perspective and think "Ok, what's wrong with this? Can I improve this?". At that point, refactoring the API into something better tends to be much more straightforward since I'm dealing with a real working "thing" rather than designing in a vacuum.

Granted, there have definitely been times where I did feel it was prudent or necessary to do a more detailed up-front design. In those cases, I certainly do so.

And than sometimes "getting something working" is just simply more important than worrying about an ideal API. So again, it's all a case-by-case judgment call.

I don't really feel that "Design Your API First" is really a *generally* correct thing for most cases and programmers. To me, that's kind of like saying "Strings are better than integers" or "Integers are better than strings". It's just too dependent on the given situation.

On Wed, 19 Jun 2013 20:25:41 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> Thanks for your clarification! This is much more helpful than the definitions of TDD that I found online (e.g. on Wikipedia).
> 
> I will say, though, that this seems to be just Yet Another Buzzword for "API design". (I'm automatically skeptical when buzzwords are involved, because all too often, buzzwords are employed to make something rather ordinary appear to be special.)

I feel the same way.

> OTOH, not all APIs should be designed to cater to the users' POV. I've encountered APIs that were *not* "convenient" in the way that I had preconceived, but in the end, it turned out that by forcing me to do things the "inconvenient" way, it not only opened up brand new ways of thinking about the problem, but also guided me into approaching the problem from an angle that is *efficient to implement*. It's just like Knuth said:
> 
> 	"People who are more than casually interested in computers
> 	should have at least some idea of what the underlying hardware
> 	is like. Otherwise the programs they write will be pretty
> 	weird."
> 
> So I think a balance needs to be struck between what users would like it to be, vs. what is a good way of approaching the problem.  API's should not be so far removed from their implementations that the resulting code becomes "pretty weird", as Knuth puts it. TDD is good and all, but there's the danger of pushing it too far and applying it where it's not applicable.
> 

Right. It's like creating a Vacuum Cleaner or a car or a kitchen appliance by designing the case, housing and controls first, and then trying to design working internals to fit that mold. Form needs to follow function.

On Thu, 20 Jun 2013 21:38:08 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2013-06-20 20:14, Sean Kelly wrote:
> 
> > And this is why the waterfall model (which TDD seems to encourage)
> > tends to be problematic.
> 
> You don't write all the test at once and then all the implementations at once. Write tests for one function first, then implement it. Then move to the next function.
> 
> Also, tests are not written in stone. They should evolve and change just as much as the rest of the code.
> 

But then at that point, where's the benefit of writing the tests first?

I can still evolve/change the tests if I wrote them after the implementation. Writing them before the implementation just means I have that much more bookkeeping *while* implementing. May as well just hold off on the tests until I have an actual interface to test against. It not like the pre-written-but-failing tests were doing me any good while I was still implementing.

I'm not saying that it's necessarily bad to write a function's tests before the function itself, I just don't see what it really matters to code the tests first. The important thing is that the tests get written, ideally before you move on to something else. If you have the discipline to write the tests before the function, then you have the discipline to write the tests after the function.

If the issue is to make sure the tests promptly get written promptly, then D's built-in unittests do far more to encourage that than TDD would seem to.

On Thu, Jun 20, 2013 at 06:37:35PM -0400, Nick Sabalausky wrote:
> On Thu, 20 Jun 2013 21:38:08 +0200
> Jacob Carlborg <doob@me.com> wrote:
[...]
> > You don't write all the test at once and then all the implementations at once. Write tests for one function first, then implement it. Then move to the next function.
> > 
> > Also, tests are not written in stone. They should evolve and change just as much as the rest of the code.
> > 
> 
> But then at that point, where's the benefit of writing the tests first?
> 
> I can still evolve/change the tests if I wrote them after the implementation. Writing them before the implementation just means I have that much more bookkeeping *while* implementing. May as well just hold off on the tests until I have an actual interface to test against.  It not like the pre-written-but-failing tests were doing me any good while I was still implementing.
> 
> I'm not saying that it's necessarily bad to write a function's tests before the function itself, I just don't see what it really matters to code the tests first. The important thing is that the tests get written, ideally before you move on to something else. If you have the discipline to write the tests before the function, then you have the discipline to write the tests after the function.
> 
> If the issue is to make sure the tests promptly get written promptly, then D's built-in unittests do far more to encourage that than TDD would seem to.

+1.

I'm guessing that part of TDD's drive is that you want to be explicit about what you expect from your code, so you set down your expectations beforehand; and since you have to do that, why not do it in the form of actually-runnable code (i.e., unittests)? Then, you work on making the code behave the way you expect.  I have no problem with the bit about setting down expectations of what the code should do -- it may help you rethink the problem from the POV of the user of your code, and possibly find better ways of structuring the solution.  But where I see TDD treading shaky ground is to singlemindedly focus on this part of the coding process to the exclusion of all else -- algorithm design, correspondence between API and implementation, efficiency considerations, etc..

I've always been a supporter of the view that the best programs are those in which code structure corresponds with data structure (a key idea in Jackson Structured Programming). Focusing on API design to the exclusion of everything else risks a mismatch between API structure and implementation structure, which leads to increased likelihood of bugs, inefficiencies, and code smells.


T

-- 
IBM = I'll Buy Microsoft!