?

Michal,

On 8/28/14 12:03 PM, Michal Svoboda pht@...
[testdrivendevelopment] wrote:
> Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote:
>> When the entire test is written up front (for a new class at least)
>> the test will fail, because a failure to compile is considered a
>> failure. The problem that I have with the approach is that when it
>> "passes", does it pass for the right reason? Or, do we have
>> unnecessary test code? or production code? Did the test ever fail for
>> the expected reason, or did it fail only in the form of a compilation
>> failure?
>
> Hi Kaleb,
>
> I hear what you are saying. But it really goes down to that gut feeling.
> Sometimes I want to see the whole story first, not just "once upon a
> time there was an object". It usually depends on what level of certainty
> I feel over my requirements. The objective is to drive the design with
> the test, not to just write it first.

I write acceptance tests all at once. I write unit tests a bit at a
time, often starting with the creation of a new object whose definition
does not yet exist. In this fashion I work inside-out within the bounds
of outside-in.

> Even if the test is written in a bigger chunk, you can still add in the
> code one bit at a time and see the test fail for various reasons until
> you get (and subsequently fix) the desired one.

With effort, you can. But how does that drive the design?

- George

--
----------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------

?

Over the last three years I've been doing training on and advocating TDD where I work and a number of people have been striving to learn and use TDD in their daily development :).

--- An experience with coworker 1 ---

One of these coworkers recently published a 6-part series on TDD that starts off assuming no prior experience with TDD ().

In part two, having recently introduced the three laws of TDD, he wrote the following ():

[Test]

public?void?Execute_delegates_to_IWidgetLoader_to_load_widget_details()

{

? ? var?activator?=?new?WidgetActivator();

?}

At this point the test fails because WidgetActivator doesn't exist. He then proceeds to introduce a dependency and a constructor parameter before making the test pass:

var?mockWidgetLoader?=?new?Mock<IWidgetLoader>();

var?activator?=?new?WidgetActivator(mockWidgetLoader.Object);

When a commenter pointed out that he was violating the three laws of TDD of he commented:

"When adding a new test, you do not stop as soon as it turns red; rather you stop when the test is completely written. Then you labor to make that test turn green by modfiying [sic] the class-under-test. Think about it this way: if you write a partial test then make it go green, you now have a passing test *that is wrong*. A test should be green if and only if it is valid."

I disagree with the comment because it allows multiple unnecessary lines of code to be written and doesn't provide a progression that guarantees that all production code is effectively "tested"/covered. It also makes it harder to get feedback from the test about the design of the system. Sure, the developer might tweak the test code to improve the API but at that point the API design isn't supported by a working implementation so it's not necessarily going to reveal design defects as quickly.

Another person pointed out that "an incomplete but green test is at best misleading and at worst wrong: if a test is green it should be a valid test, and a partial or incomplete test is not valid."

--- An experience with coworker 2 ---

Coworker 2 recently came to me with some questions. He described his process wherein he would:

* Create an empty test

* Add a variable assignment: var instance = new MyClass();

* Introduce the class

* Add dependency1 to that class: var instance = new MyClass(dep1);

* Add that dependency as a constructor parameter

* Add dependency2 to that class: var instance = new MyClass(dep1, dep2);

* Call the method to be under test: var result = instance.Execute();

* Define the method under test

* Add a parameter to the callsite of the method under test: var result = instance.Execute(param1);

* Add the new parameter to the implementation of the method under test

* Add another parameter to the callsite of the method under test: var result = instance.Execute(p1, p2);

* ...

The story, in short, is that no matter what he was doing extremely small steps -- steps that felt unnaturally small to me. Ultimately he had a number of problems which seemed to be because he wasn't letting the tests guide the implementation but he felt the implementation went really slowly because after writing a fair amount of code and he'd have to come back and modify many of his tests when a new parameter to a method needed to be added.?

I introduced him to ATDD/double-loop TDD in hopes that it'd help him work in vertical slices, let the system evolve, and help him discover the required parameters/dependencies early in the process.

--- Questions ---

Both of the above experiences and questions go back to understanding the three laws of TDD and step size. As I'm entirely self taught, I'd like to know your thoughts.

Do you strictly follow the three laws of TDD as literally written?

What step size do you typically have when going back and forth between tests and code?

How do you decide the appropriate step size?

When writing a test, do you define a method or constructor with all its expected parameters?

Do you consider, "an incomplete but green test is at best misleading and at worst wrong"?

Thank you for the feedback.

--Kaleb

?

Hi Kaleb,

Regarding "an incomplete but green test is at best misleading and at worst wrong: if a test is green it should be a valid test, and a partial or incomplete test is not valid."

... If I think about using, say, a tool like Infinitest that is constantly running tests, it reports green against "incomplete" tests, and I'm ok with that. So I don't think it's "wrong" per se.

I've both strictly followed the three laws and not. For me, it depends upon tools and problem at hand, as others have suggested. Mostly, I fix things that are obvious problems at the earliest possible opportunity rather than wait, but I'm not dogmatic about it.

Jeff

Langr Software Solutions, Inc.

Modern C++ Programming with TDD ()

Agile in a Flash ()

Agile Java: Crafting Code with Test-Driven Development

? ()

On Tue, Aug 26, 2014 at 9:48 AM, Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

Over the last three years I've been doing training on and advocating TDD where I work and a number of people have been striving to learn and use TDD in their daily development :).

--- An experience with coworker 1 ---

One of these coworkers recently published a 6-part series on TDD that starts off assuming no prior experience with TDD ().

In part two, having recently introduced the three laws of TDD, he wrote the following ():

[Test]

public?void?Execute_delegates_to_IWidgetLoader_to_load_widget_details()

{

? ? var?activator?=?new?WidgetActivator();

?}

At this point the test fails because WidgetActivator doesn't exist. He then proceeds to introduce a dependency and a constructor parameter before making the test pass:

var?mockWidgetLoader?=?new?Mock<IWidgetLoader>();

var?activator?=?new?WidgetActivator(mockWidgetLoader.Object);

When a commenter pointed out that he was violating the three laws of TDD of he commented:

"When adding a new test, you do not stop as soon as it turns red; rather you stop when the test is completely written. Then you labor to make that test turn green by modfiying [sic] the class-under-test. Think about it this way: if you write a partial test then make it go green, you now have a passing test *that is wrong*. A test should be green if and only if it is valid."

I disagree with the comment because it allows multiple unnecessary lines of code to be written and doesn't provide a progression that guarantees that all production code is effectively "tested"/covered. It also makes it harder to get feedback from the test about the design of the system. Sure, the developer might tweak the test code to improve the API but at that point the API design isn't supported by a working implementation so it's not necessarily going to reveal design defects as quickly.

Another person pointed out that "an incomplete but green test is at best misleading and at worst wrong: if a test is green it should be a valid test, and a partial or incomplete test is not valid."

--- An experience with coworker 2 ---

Coworker 2 recently came to me with some questions. He described his process wherein he would:

* Create an empty test

* Add a variable assignment: var instance = new MyClass();

* Introduce the class

* Add dependency1 to that class: var instance = new MyClass(dep1);

* Add that dependency as a constructor parameter

* Add dependency2 to that class: var instance = new MyClass(dep1, dep2);

* Call the method to be under test: var result = instance.Execute();

* Define the method under test

* Add a parameter to the callsite of the method under test: var result = instance.Execute(param1);

* Add the new parameter to the implementation of the method under test

* Add another parameter to the callsite of the method under test: var result = instance.Execute(p1, p2);

* ...

The story, in short, is that no matter what he was doing extremely small steps -- steps that felt unnaturally small to me. Ultimately he had a number of problems which seemed to be because he wasn't letting the tests guide the implementation but he felt the implementation went really slowly because after writing a fair amount of code and he'd have to come back and modify many of his tests when a new parameter to a method needed to be added.?

I introduced him to ATDD/double-loop TDD in hopes that it'd help him work in vertical slices, let the system evolve, and help him discover the required parameters/dependencies early in the process.

--- Questions ---

Both of the above experiences and questions go back to understanding the three laws of TDD and step size. As I'm entirely self taught, I'd like to know your thoughts.

Do you strictly follow the three laws of TDD as literally written?

What step size do you typically have when going back and forth between tests and code?

How do you decide the appropriate step size?

When writing a test, do you define a method or constructor with all its expected parameters?

Do you consider, "an incomplete but green test is at best misleading and at worst wrong"?

Thank you for the feedback.

--Kaleb

?

A rule of thumb I followed for many years was to leave a failing test when taking a break.

Charlie

On Aug 27, 2014 6:41 AM, "Tim Ottinger tottinge@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

?

Never trust a test you have never seen fall.

Tests can pass for the wrong reasons.

You have to trust then or get rid of them.

That said, there are intermediate steps which are legitimately green on your way to completing a more significant goal.

That only leaves a few little procedural questions.

How long does it remain incomplete?

How do you denote that it is incomplete?

How do you website you don't abandon it?

Most of the time you work one test to completion before check-in or taking a break so it is a non-issue.

But if you are forced to leave our for a while, these things matter.

On Aug 27, 2014 3:09 AM, "Samuel ?slund samuel@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote:

?

Do you consider, "an incomplete but green test is at best misleading and at worst wrong"?

You might want to consider the difference between a test during development locally and a test that have been checked in to the common repository.

I have been confused by tests with names saying they check something that is not checked, making me spend time searching for problem in the wrong place.
On the other hand during TDD it is rather important to know that the test actually fails, like you and others describe. The key as I see it is if the test is committed or not. Mostly the tests confusing me have come from being interupted while they happened to be green and then missing that they was not compete when coming back.

Regards,
//Samuel

?

Never trust a test you have never seen fall.

Tests can pass for the wrong reasons.

You have to trust then or get rid of them.

That said, there are intermediate steps which are legitimately green on your way to completing a more significant goal.

That only leaves a few little procedural questions.

How long does it remain incomplete?

How do you denote that it is incomplete?

How do you website you don't abandon it?

Most of the time you work one test to completion before check-in or taking a break so it is a non-issue.

But if you are forced to leave our for a while, these things matter.

On Aug 27, 2014 3:09 AM, "Samuel ?slund samuel@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote:

?

Do you consider, "an incomplete but green test is at best misleading and at worst wrong"?

You might want to consider the difference between a test during development locally and a test that have been checked in to the common repository.

I have been confused by tests with names saying they check something that is not checked, making me spend time searching for problem in the wrong place.
On the other hand during TDD it is rather important to know that the test actually fails, like you and others describe. The key as I see it is if the test is committed or not. Mostly the tests confusing me have come from being interupted while they happened to be green and then missing that they was not compete when coming back.

Regards,
//Samuel

On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote:

?

Do you consider, "an incomplete but green test is at best misleading and at worst wrong"?

You might want to consider the difference between a test during development locally and a test that have been checked in to the common repository.

I have been confused by tests with names saying they check something that is not checked, making me spend time searching for problem in the wrong place.
On the other hand during TDD it is rather important to know that the test actually fails, like you and others describe. The key as I see it is if the test is committed or not. Mostly the tests confusing me have come from being interupted while they happened to be green and then missing that they was not compete when coming back.

Regards,
//Samuel

?

?

On 14/8/26 17:48, Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote:

?

Do you consider, "an incomplete but green test is at best misleading and at worst wrong"?

You might want to consider the difference between a test during development locally and a test that have been checked in to the common repository.

I have been confused by tests with names saying they check something that is not checked, making me spend time searching for problem in the wrong place.
On the other hand during TDD it is rather important to know that the test actually fails, like you and others describe. The key as I see it is if the test is committed or not. Mostly the tests confusing me have come from being interupted while they happened to be green and then missing that they was not compete when coming back.

Regards,
//Samuel