On 2013-06-20 00:34, Jonathan M Davis wrote:

> So, I think that it's clear that I will never agree with TDD. If someone else
> wants to code that way, and it works for them, great, but it's not how I want
> to function.

No, but that's how your functions should function :)

-- 
/Jacob Carlborg

On 2013-06-20 00:47, Nick Sabalausky wrote:

> - Writing a unittest first forces the API to be designed before the
>    implementation is written. But implementation is necessary to flush
>    out unexpected design requirements (If you think you can always
>    come up with an appropriate design and interface before
>    implementing, then you're just plain wrong). Sometimes the
>    appropriate design and API is obvious. Sometimes it isn't. When it
>    isn't, then TDD skirts dangerously close to some of the problems of
>    "Waterfall Model". Sure, TDD advocates refactoring-as-needed, but I
>    can do that with or without TDD.

Just because you have written a test doesn't mean you cannot change it. Perhaps you come up with a better API design, then change the tests.

-- 
/Jacob Carlborg

On Thursday, 20 June 2013 at 09:02:49 UTC, Chris Cain wrote:
> On Thursday, 20 June 2013 at 07:36:41 UTC, Paulo Pinto wrote:
>> ...
>> Just left enough context to ask the following question, I hope I did not left out too much.
>>
>> How does TDD then help how a user of my application will use the application UI?
>>
>> This is the area where I usually make TDD evangelists go speechless in conferences, as they start to present ad-hoc solutions and end up changing subject.
>>
>> --
>> Paulo
>
> Sure. The user, in this case, isn't the user of your application. The "user" is the person using your API (other programmers). TDD has nothing to do with the visual design of your application and everything to do with the software engineering design. It's to help guide you to the answer to the questions "how should I define the behavior of this class/how should this class be used in practice?"

UI is also code, composed by functions/classes/markup, depending on the
language and framework.

How to use TDD to write a class for an owner drawn control in Win32 as an example?

This is the issue that TDD fails, but TDD advocates keep on selling it.

--
Paulo

On Thursday, 20 June 2013 at 10:13:53 UTC, Jacob Carlborg wrote:
> On 2013-06-20 00:47, Nick Sabalausky wrote:
>
>> - Writing a unittest first forces the API to be designed before the
>>   implementation is written. But implementation is necessary to flush
>>   out unexpected design requirements (If you think you can always
>>   come up with an appropriate design and interface before
>>   implementing, then you're just plain wrong). Sometimes the
>>   appropriate design and API is obvious. Sometimes it isn't. When it
>>   isn't, then TDD skirts dangerously close to some of the problems of
>>   "Waterfall Model". Sure, TDD advocates refactoring-as-needed, but I
>>   can do that with or without TDD.
>
> Just because you have written a test doesn't mean you cannot change it. Perhaps you come up with a better API design, then change the tests.

When I start something, it isn't always clear what mental model of the problem fit best the problem. I usually wait until I know I have a consistent mental model of the problem to write test. Otherwise, tests tend to get into your way to change the API( because you need to change tests as well. I start writing test when I know what kind of API make sense (it isn't always finished, but I know what it will look like overall).

Which lead to TITMOD, test in the middle of dev.

On 6/20/13 5:49 AM, Jacob Carlborg wrote:
> 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

This is reasonable.

> Example, write a compiler:
>
> Problem: Lex string literals
>
> Test:
>
> auto code = `"asd"`;
> auto token = lex(code);
> assert(token.lexeme == code);
> assert(token.type == Type.stringLiteral);
>
> Implementation:
>
> Write the implementation to pass the above test.
>
> Token lex (string code)
> {
> return Token(code, Type.stringLiteral);
> }
>
> This is obviously a dummy implementation but it's enough to pass the
> test.

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.


Andrei

On Thursday, 20 June 2013 at 14:46:30 UTC, 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.
>

There is this war story about the team coding some early version of Excel. The management decided to put very severe deadline on when features. Many dev ended up writing method like this, so the feature can be delivered in time, as it is now a bug if it fails.

On Thu, Jun 20, 2013 at 06:52:26PM +0200, deadalnix wrote:
> On Thursday, 20 June 2013 at 14:46:30 UTC, 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.
> >
> 
> There is this war story about the team coding some early version of Excel. The management decided to put very severe deadline on when features. Many dev ended up writing method like this, so the feature can be delivered in time, as it is now a bug if it fails.

That's terrible. It encourages the kind of sloppy coding that makes so much "enterprise" code look nastier than what a highschool dropout writes in his sleep.

OTOH it explains a lot of things about why early versions of Excel were so atrocious. :-P


T

-- 
It only takes one twig to burn down a forest.

On Jun 19, 2013, at 2:59 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 
> It's not necessarily the case that you write _all_ of the tests and then all of the code, but as I understand it, with TDD, you write a test for a function before you write that function (though both could be written well before other functions and whatever tests go with them). And I completely disagree with the idea of writing a test for a piece of code that doesn't exist yet, even if you're going to write it immediately after writing the test.

The video is quite good but takes a long time to get to the really interesting stuff.  Regarding TDD, one point he makes that seems worth repeating is that by focusing on the behavior of single functions you're really just doing bottom-up design.  He mentions some studies or at least anecdotes from projects that tried TDD and they all agreed that as time went on, their code entropy increased, which seems to support the idea that TDD at least encourages people to do bottom-up design.

The more interesting point he makes, however, is about how difficult it is to understand and therefore accurately test object-oriented programs by virtue of how such programs are traditionally built.  So the problem really isn't so much TDD as that it's often difficult to derive anything truly useful from the results.  He then goes on to talk about DCI (Data Context Interaction), which is essentially a different way to build OO apps that more closely models what the apps actually do.  So you could really use TDD in combination with this DCI design approach and end up with something a lot more useful.

On Jun 19, 2013, at 3:00 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, June 19, 2013 14:19:28 H. S. Teoh wrote:
>> Doesn't TDD stand for Test-Driven *Design*?
> 
> It was my understanding that it was Test-Driven "Development," but I could be wrong. Let's see... Well, according to Wikipedia, it's development, not design:
> 
> http://en.wikipedia.org/wiki/Test-driven_development

Apparently, the original word was "Design" and the creator laments the fact it's too late to change it back.

On Jun 19, 2013, at 4:44 PM, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/19/2013 3:23 PM, Szymon Gatner wrote:
>> Point of TDD for a square root function would be to create a good API for getting a square root of a number. Implementation is just a detail.
> 
> I just can't accept that. For one thing, implementation details often must drive the interface. Just writing specs without any knowledge of how it would be implemented will not produce an efficient design.
> 
> For the square root, there's a definite tradeoff between accuracy and speed. With no knowledge of those tradeoffs, and just coming up with a spec, how can you make the right decisions?

And this is why the waterfall model (which TDD seems to encourage) tends to be problematic.  That said, I do like the idea of building a program in a way that is testable right from the start, because it can be very hard to bolt on testing after the fact.  For example, basically all the work I do is with distributed programming, which requires extensive mocking to produce any sort of meaningful test.  If the API wasn't designed to allow this, about the only testing that can be done is black-box testing using external apps.