On 2013-06-19 19:52, Paulo Pinto wrote:

> - applications done in native languages with third party libraries only

When I write a test for my own code that uses third party code or services I assume that they work 100% and will never fail. That's because I'm testing MY code not the third party code. For services it's also a good idea to mock them.

-- 
/Jacob Carlborg

On Wed, Jun 19, 2013 at 11:06:26PM +0200, Jacob Carlborg wrote:
> On 2013-06-19 19:29, H. S. Teoh wrote:
> 
> >Producing "minimal code" that satisfies the test simply gets you stuck in local minima without ever getting any nearer an actual solution for the problem.
> 
> Then your test doesn't cover enough cases.

How do you write a test that covers "enough" cases for a sudoku solver?


> >Before methodologies like TDD could even begin to work, one has to *solve* the problem at hand first -- analyse the problem, explore its structure, invent an algorithm, then one can verify the correctness of one's implementation with unittests. You have to already have an idea about how things are going to work, before TDD can help you.
> 
> I agree. I haven't watch the video(s) but I think TDD is for testing
> an implementation not a design.
[...]

Doesn't TDD stand for Test-Driven *Design*?


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley

On 06/19/2013 08:58 PM, Jonathan M Davis wrote:
> Exactly. With TDD, you write the tests and then write the code

Isn't this what is highlighted in the second article linked to by the OP, as being precisely one of the misinterpretations of TDD?

I'm not sure if I've misinterpreted you here, because one needs to distinguish between "write all tests first, then code" (which is not what TDD means) and the rather tighter iteration/co-evolution of test and code writing which is supposed to characterize TDD.  If you meant the latter then I apologize.

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.

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

On Wednesday, June 19, 2013 22:27:57 Joseph Rushton Wakeling wrote:
> On 06/19/2013 08:58 PM, Jonathan M Davis wrote:
> > Exactly. With TDD, you write the tests and then write the code
> 
> Isn't this what is highlighted in the second article linked to by the OP, as being precisely one of the misinterpretations of TDD?

I haven't read the article yet, so I don't know.

> I'm not sure if I've misinterpreted you here, because one needs to distinguish between "write all tests first, then code" (which is not what TDD means) and the rather tighter iteration/co-evolution of test and code writing which is supposed to characterize TDD. If you meant the latter then I apologize.

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.

I _do_ agree with writing the tests fora function as soon as the function is done, in which case, you're likely going to have to do more work on the function, since it'll probably fail the test, and you'll probably improve the tests some more at that point as well. But I completely disagree with writing the test before the code, which is one of the key features of TDD as its always been explained to me.

- Jonathan M Davis

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

- Jonathan M Davis

On Wednesday, 19 June 2013 at 21:21:09 UTC, H. S. Teoh wrote:
> [...]
>
> Doesn't TDD stand for Test-Driven *Design*?
>

It stands for Test-Driven "Development". Often people focus on the word "test" too much forgetting that is is actually only a "force" that drives development. TDD is not the same as Unit Testing which is all about tests.

Definitions may vary but TDD folk agree that it is about evolving the design incrementally, test by test (test comes of course fists and represents new feature request) and abandoning "big upfront design". That quote actually comes from uncle Bob himself - one of the authors of Agile Manifesto and big TDD advocate.

In the talk I originally linked Jim actually openly disagrees with uncle Bob on a claim that TDD improves quality of the code. And by quality they mean quality of the design not run-time correctness.

Am 19.06.2013 23:11, schrieb Jacob Carlborg:
> On 2013-06-19 19:52, Paulo Pinto wrote:
>
>> - applications done in native languages with third party libraries only
>
> When I write a test for my own code that uses third party code or
> services I assume that they work 100% and will never fail. That's
> because I'm testing MY code not the third party code. For services it's
> also a good idea to mock them.
>

The issue is not to test third party libraries, far from it.

The problem is that you cannot mock them, specially if you rely a lot on
non virtual methods or pure function calls. Or on framework code that
calls your code back, after certain events happened in the system.

To do that properly, you end up wrapping third party code into code that can be replaced for unit tests execution, thus making the test effort an herculean task.

Good luck convincing any project manager on the enterprise world that
wrapping third party code to ease unit testing is worthwhile.

--
Paulo

On Wednesday, 19 June 2013 at 21:59:21 UTC, Jonathan M Davis wrote:
>
> I _do_ agree with writing the tests fora function as soon as the function is
> done, in which case, you're likely going to have to do more work on the
> function, since it'll probably fail the test, and you'll probably improve the
> tests some more at that point as well. But I completely disagree with writing
> the test before the code, which is one of the key features of TDD as its
> always been explained to me.

Writing the test before writing the function is exactly the point of TDD. It forces you to think about parameters it should take and value(s) it should return first. You first write the code that uses that function and only when client code looks ok and and all requirements are understood, only then you implement the feature.

API change cost is way higher than fixing a bug inside a function or a class, also you will often realize that what you initially though was necessary turns out not to be after all.

On Wednesday, 19 June 2013 at 21:54:04 UTC, 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.
>
> D's support of unit testing is not an endorsement of TDD.

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. Good class design is way harder to achieve then correct implementation. Libraries become unusable in time not because they did what they did wrong but because they were badly structured / designed.

TDD claims to help with this by forcing you to code client code first (the test) which arguably leads to better decoupling of components. You don't have to split components for reuse later because they are already being used in unrelated contexts in tests.