Re: [TDD] Three Law of TDD - to strictly follow, or not?

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:

Show quoted text

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

Re: [TDD] Three Law of TDD - to strictly follow, or not?

#35579

Hi Kaleb,

On Tue, Aug 26, 2014 at 4:48 PM, Kaleb Pederson
kaleb.pederson@... [testdrivendevelopment]
<testdrivendevelopment@...> wrote:
[...]
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();Stop!  Go back to where you had the empty test. Now, write the assert
that matches the intent of the test. It (probably) won't compile, but
at least you have the assert, and that's what drives everything else.
Now fill in enough details so that the test compiles, etc.

In general, if you think of a test as Arrange / Act / Assert, work
backwards: Assert first, then Act, then Arrange. This is the TDD
process in action /within/ the test.
Cheers,
    Kevin
-- 
 -- remote one-to-one tutoring in TDD and OO
 -- software development coaching
 -- Refactoring in Ruby, the book

Re: [TDD] Three Law of TDD - to strictly follow, or not?

#35578

Hi Kaleb,

Do you strictly follow the three laws of TDD as literally written?No, but when I get into trouble, I stop, back up and get more precise
about how I'm proceeding.

What step size do you typically have when going back and forth between tests and code?There should be no "typical" step size in your practice. Beck stressed
the importance of learning
to "shift gears" - to go at various speeds based on your needs at the
moment. Sometimes you can
move ahead successfully in big steps, sometimes you need to go slower.
Practice both.

Imagine if you decide to always move at a certain speed, without
regard to the terrain. Either you
would be moving at a ridiculously slow pace on the sidewalk or running
down rocky hillsides. Either
one could get you in trouble.

How do you decide the appropriate step size?A combination of what I'm doing - is it similar to something I've done
before for example - and
how I'm doing - how well are things moving along. When I go too fast -
too big steps - things start
to feel uncomfortable and I slow down.

When writing a test, do you define a method or constructor with all its expected parameters?I define it with the parameters I know of and have available a the
moment. Code is really easy to
change and there's no reason to put everything in when I don't yet
know for sure what I need or
where I will get the parameters.

Do you consider, "an incomplete but green test is at best misleading and at worst wrong"?No. Except in the sense that any test could be wrong. A test tests
what it tests. You have to
be aware of what you are testing and what you have not yet tested. No
single test is "complete"
in any meaninful sense of the word.

Charlie

Re: [TDD] Three Law of TDD - to strictly follow, or not?

#35577

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

> This is something I will let evolve as I add more tests. ?It seems like the pain your coworker was feeling could be down to not refactoring the test itself. ?Instantiating the class under test multiple times in a test is what I would consider to be duplication

?

In some ways you're exactly correct. He could have used a factory method to extract out duplication in the creation code. But at other times no. He would sometimes write 15 tests for a method and then add a new parameter to the method under test resulting in the need to modify 15 tests. I believe he was doing too much iceberg testing -- that is, he was trying to test an "iceberg" through a small whole rather than testing the individual methods. He hadn't yet tied in how SRP and small units improve the overall TDD experience.

> You said "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.". ?I'd like to ask why you think this? ?Each of my tests are small and cover essentially at most one path through the code.

I'll answer that in parts:

1) Assuming each test has some setup -- each of those lines in the test needs to be "tested". In other words, we should be able to see a failure indicating that line in the test is necessary. If we have not seen the "failure" it's possible that we have made an error in the setup which increases the likelihood that we'll have to debug the test.

2) When we write the whole test without having supported it with the necessary production code, the production code, though testable, will not have had the same opportunity to evolve as it would have had it been co-developed with the tests. To put this another way and refer to J.B. Rainsberger's Queueing Theory post, we've lost the feedback loop between each line in the test and the production code. IMO, when we write the entirety of the test before writing any production code we're more likely to mentally create a design and go with it rather than letting it evolve fluidly.

3) When we don't co-develop the production code with the tests, we've also elongated the time between having a passing unit test and the corresponding implementation which again increases the likelihood that we'll need to debug something or attempt a jump that's too big.

Thank you for your response and questions Colin. Overall, I feel pretty much the same way. Much of what I do is gut feel. Sometimes I will indeed write a whole test before writing the production code, but at other times I'll follow the three laws of TDD to the letter.

My hope was that by asking these questions and eliciting feedback I could move from tacit knowledge to explicit knowledge and thereby be better at TDD and better able to help others.

--Kaleb

On Tue, Aug 26, 2014 at 10:04 AM, Colin Vipurs zodiaczx6@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

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

No. ?But I don't follow anything strictly!
?

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

This varies greatly depending on what I'm working on/how comfortable I am with everything. ?When working with a new language/framework etc. my steps will usually be very small as I'm trying to figure things out as I go along. ?If I'm in vanilla Java doing things I've done before the steps will be bigger as I'm more comfortable. ?Kent described this in his book but referred to it as "gears" not steps

How do you decide the appropriate step size?

See above + some gut feeling
?

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

This is something I will let evolve as I add more tests. ?It seems like the pain your coworker was feeling could be down to not refactoring the test itself. ?Instantiating the class under test multiple times in a test is what I would consider to be duplication

?

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

Yes, but only for a certain degree of "incomplete" :)

You said "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.". ?I'd like to ask why you think this? ?Each of my tests are small and cover essentially at most one path through the code. ?

?

Thank you for the feedback.

--Kaleb

--
Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.

Re: [TDD] Three Law of TDD - to strictly follow, or not?

#35576

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

No. ?But I don't follow anything strictly!

?

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

This varies greatly depending on what I'm working on/how comfortable I am with everything. ?When working with a new language/framework etc. my steps will usually be very small as I'm trying to figure things out as I go along. ?If I'm in vanilla Java doing things I've done before the steps will be bigger as I'm more comfortable. ?Kent described this in his book but referred to it as "gears" not steps

How do you decide the appropriate step size?

See above + some gut feeling

?

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

This is something I will let evolve as I add more tests. ?It seems like the pain your coworker was feeling could be down to not refactoring the test itself. ?Instantiating the class under test multiple times in a test is what I would consider to be duplication

?

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

Yes, but only for a certain degree of "incomplete" :)

You said "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.". ?I'd like to ask why you think this? ?Each of my tests are small and cover essentially at most one path through the code. ?

?

Thank you for the feedback.

--Kaleb

--
Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.

Re: [TDD] Three Law of TDD - to strictly follow, or not?

#35575

The official rules say to write a test, but only enough of a test to get a failure --- which means "not the whole test."

But as to the title question: sometimes you should follow the rules strictly. Other times you might try not.?

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

Show quoted text

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

--

Tim Ottinger, Anzeneer, Industrial Logic
-------------------------------------

Three Law of TDD - to strictly follow, or not?

#35574

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

PDF Unit

#35573

Hi,

Does anyone know of a good unit testing library for testing pdf in .NET?

something similar to jPDFUnit?

--

Lior?Friedman

Agile Consultant -?AUT/TDD?Expert?| Mobile: 972.52.833.3660 | Email:?lior@...??

Blog -?

P.S. Follow me on??&?. See you there…

Test Tools/Gem for ADA 509 Compliance

Camille Bell

#35572

We've been using Ruby and Cucumber for ATDD/BDD, using PageObject and some other cool Ruby gems with Watir/Selenium drivers. We've found that approach preferable to using Cucumber-JVM or SpecFlow, even though the apps we're testing aren't being written in Ruby or Rails.

Some of my colleagues would like to automate testing of the American's for Disability Act 509 compliance, others of us think 509 compliance is something better done manually.

In any case, does anyone on this forum know of a good Ruby gem for 509 compliance? If not, do you know of any other good approaches to automate testing of 509 compliance (open to non- Ruby options, if there isn't a good Ruby alternative).

thanks,

Camille

Re: [TDD] current recommendations for tdd?

#35571

I think you'll need:

- A good unit-testing library;

- A good matcher/fluent-assertions library; and

- A good mock library

- A?good UI-testing framework (whether you plan to test UI)

IMHO, I recommend you to take a look at these libraries:

- TestNG (http://testng.org/): easier (and has better features) than JUnit;

- FEST-Assertions (https://github.com/alexruiz/fest-assert-2.x): It makes your assertions more fluent. I prefer using it than Hamcrest (https://github.com/hamcrest/JavaHamcrest), but it's just my personal taste;

- Mockito (https://code.google.com/p/mockito/): easier-to-construct mocks

UI testing:

- Selenium (http://docs.seleniumhq.org/), for Web/iOS/Android-Web applications

- Robotium (https://code.google.com/p/robotium/) for Android native/web applications

- FEST (http://docs.codehaus.org/display/FEST/Home) for Swing applications

?

Best regards,

- Thiago Delgado Pinto

Re: [TDD] current recommendations for tdd?

#35570

Definitely JUnit. Also check out Mockito and AssertJ.?

Show quoted text

On Sunday, July 27, 2014, Michal Svoboda pht@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

Asim Jalis asimjalis@... [testdrivendevelopment] wrote:
> What are current recommendations for tools in Java?

Just junit, and perhaps guava libraries to get around some java deficiency.

Michal

Re: [TDD] current recommendations for tdd?

#35569

Asim Jalis asimjalis@... [testdrivendevelopment] wrote:
What are current recommendations for tools in Java?Just junit, and perhaps guava libraries to get around some java deficiency.

Michal

Re: [TDD] current recommendations for tdd?

Asim Jalis

#35568

开云体育

What are current recommendations for tools in Java?

On Jul 23, 2014, at 1:38 AM, "Paul Mackintosh pnm@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

Show quoted text

?

People have told you about tools, as far as practices go I would recommend Ian Cooper's video TDD Where Did It All Go Wrong, it explains how the original ideas around testing units of behaviour (as in Kent Beck TDD by example) got a bit distorted and then explains how it should work

On 22 Jul 2014, at 18:37, "andrew.d.ciccarelli@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

?

Hello, I was curious about the current state of TDD. Obviously, it's 10+ years old at this point. I wanted to find out which practices and tools are currently favored for TDD. I'm guessing that these may have evolved a bit over the years.

I'm a .NET developer. I prefer simple design for unit test implementation. I prefer to use free tools for unit testing. Which practices and tools would you use/recommend if starting a new .NET project from scratch today?

Re: [TDD] current recommendations for tdd?

#35567

开云体育

People have told you about tools, as far as practices go I would recommend Ian Cooper's video TDD Where Did It All Go Wrong, it explains how the original ideas around testing units of behaviour (as in Kent Beck TDD by example) got a bit distorted and then explains how it should work

On 22 Jul 2014, at 18:37, "andrew.d.ciccarelli@... [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

Show quoted text

?

Hello, I was curious about the current state of TDD. Obviously, it's 10+ years old at this point. I wanted to find out which practices and tools are currently favored for TDD. I'm guessing that these may have evolved a bit over the years.

I'm a .NET developer. I prefer simple design for unit test implementation. I prefer to use free tools for unit testing. Which practices and tools would you use/recommend if starting a new .NET project from scratch today?

Re: [TDD] current recommendations for tdd?

#35566

NUNit (with testcase attributes), FakeItEasy, NCrunch = awesome

On Wed, Jul 23, 2014 at 9:55 AM, 'Donaldson, John' john.m.donaldson@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

Show quoted text

?

Yes, NUnit is wonderful and Moq.

If you’re using Visual Studio the built-in unit test framework is reasonable and well-integrated.

And then add – ReSharper.

?

John D.

?

From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 22 July 2014 23:00
To: testdrivendevelopment@...
Subject: Re: [TDD] current recommendations for tdd?

?

TDD, or at least the ideas behind it, is a lot older than that.?

?

NUnit and SpecFlow are both pretty awesome.?

?

There are also a number of good mock tools: NSubstitute, Rhino, Moq, etc. You should play with a few to find?a style that suits you.?

On Tuesday, July 22, 2014, andrew.d.ciccarelli@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

Hello, I was curious about the current state of TDD. Obviously, it's 10+ years old at this point. I wanted to find out which practices and tools are currently favored for TDD. I'm guessing that these may have evolved a bit over the years.

?

I'm a .NET developer. I prefer simple design for unit test implementation. I prefer to use free tools for unit testing. Which practices and tools would you use/recommend if starting a new .NET project from scratch today?

--

Thanks,

Roy Osherove

?? -
? ?- Read my new book

? ?- Or and Continuous Delivery
? ?- +47-96-90-22-15 (Oslo Time)

Re: [TDD] current recommendations for tdd?

Donaldson, John

#35565

开云体育

Yes, NUnit is wonderful and Moq.

If you’re using Visual Studio the built-in unit test framework is reasonable and well-integrated.

And then add – ReSharper.

?

John D.

?

Show quoted text

From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 22 July 2014 23:00
To: testdrivendevelopment@...
Subject: Re: [TDD] current recommendations for tdd?

?

TDD, or at least the ideas behind it, is a lot older than that.?

?

NUnit and SpecFlow are both pretty awesome.?

?

There are also a number of good mock tools: NSubstitute, Rhino, Moq, etc. You should play with a few to find?a style that suits you.?

On Tuesday, July 22, 2014, andrew.d.ciccarelli@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

Hello, I was curious about the current state of TDD. Obviously, it's 10+ years old at this point. I wanted to find out which practices and tools are currently favored for TDD. I'm guessing that these may have evolved a bit over the years.

?

I'm a .NET developer. I prefer simple design for unit test implementation. I prefer to use free tools for unit testing. Which practices and tools would you use/recommend if starting a new .NET project from scratch today?

Re: [TDD] current recommendations for tdd?

#35564

TDD, or at least the ideas behind it, is a lot older than that.?

NUnit and SpecFlow are both pretty awesome.?

There are also a number of good mock tools: NSubstitute, Rhino, Moq, etc. You should play with a few to find?a style that suits you.?

On Tuesday, July 22, 2014, andrew.d.ciccarelli@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

Show quoted text

?

Hello, I was curious about the current state of TDD. Obviously, it's 10+ years old at this point. I wanted to find out which practices and tools are currently favored for TDD. I'm guessing that these may have evolved a bit over the years.

I'm a .NET developer. I prefer simple design for unit test implementation. I prefer to use free tools for unit testing. Which practices and tools would you use/recommend if starting a new .NET project from scratch today?

current recommendations for tdd?

[email protected]

#35563

Hello, I was curious about the current state of TDD. Obviously, it's 10+ years old at this point. I wanted to find out which practices and tools are currently favored for TDD. I'm guessing that these may have evolved a bit over the years.

I'm a .NET developer. I prefer simple design for unit test implementation. I prefer to use free tools for unit testing. Which practices and tools would you use/recommend if starting a new .NET project from scratch today?

[Tool] Automated functional tests

#35562

Hello folks,

I created a simple opensource tool for testing user interfaces called FunTester (http://funtester.org), and I would like to hear your thoughts about it. It is a model-based testing tool, and generates and executes functional tests from use case specifications. The tool is still under development and doesn't have all the features (and documentation) I wish it had. The interesting about it is that it generates tests with data and oracles, combine different use cases, use techniques such as Equivalence Partitioning and Boundary-Value Analysis, and can use test data from external sources, such as relational databases.?

The current version generates tests for Java Swing user interfaces with TestNG and FEST. We just started creating another plug-in for Selenium + JUnit/TestNG. Plug-ins can be created for (generating code into) any programming language and unit/GUI testing frameworks (i.e. Python, Ruby, PHP, C#, ...).

As the tests can be generated *before* the software is implemented, the software can be implemented to pass the functional tests.

Glad to hear your thoughts,
- Thiago Delgado Pinto

Re: [TDD] Testing a class which utilizes randomness

#35561

no two strings are ever the same.

Ever? ?Is that even possible?

What does close enough mean? Can they be UUIDs and GUIDs and be "close enough"? Or do they need to be *random* and non-repeating??

?

What I want to test is exactly this behavior - the code which discards the duplicate and forces the string to be regenerated. To test that, I need to force the random string generator to return a duplicate at least once (but finite number of times). To create the test which would generate strings until there's at least one duplicate is unrealistic, because such a test could take a very long time to complete.

How would I write such a test?

by separating concerns.?

You have string generation.

You have duplicate rejection.

You can test duplicate rejection with a mock string generator.

You can test randomness of string generations.... aw, heck, looks like you need stats and algo gurus. Math, not a billion unit tests for the algorithm.

?

--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------