headers
Charlie Poole | 3 May 2009 09:19
Favicon

ANN: NUnit 2.5 Final Release

Hi All,

The NUnit 2.5 final release is now available at
http://nunit.org/?p=download.

NUnit 2.5 is a very big release, so you'll have to read the release notes at
http://nunit.org/? p=releaseNotes&r=2.5 for the full story. But here are ten
reasons to give it a try...

1. Parameterized (data-driven) tests are supported, with features similar to
those found in mbUnit and  xUnit.net.

2. Theories - as used in JUnit- are supported fully, including support for
Assume.That.

3. New attributes allow the specifying the thread and apartment state
requirements of a test.

4. Exception handling can now be moved into the test code using
Assert.Throws or the
Throws.Exception syntax.

5. Test methods and fixtures may now be generic and many asserts and
constraint expressions now support  generic syntax.

6. Many constraints now permit substitution of a user-defined comparison
algorithm through the Using modifier. Lambda expressions are supported.

7. Test execution may now take place in a separate process for better
isolation.
(Continue reading)

Permalink | Reply | 1 comment |
headers
J. B. Rainsberger | 5 May 2009 08:06
Picon

Re: Singleton problem

On Sun, Apr 19, 2009 at 4:55 PM, kalle anka <ankeborg5001 <at> hotmail.com> wrote:

> The problem with this is that you have to make changes to the
> Singleton and I am not a permitted to do that.
> I am stuck with this module of the system.
>
> This pattern is really nice, and it would be nice if I could use it
> but as it is right now its not possible.

You can also introduce a new class, SingletonWrapper that delegates
its methods to the Singleton. From there, extract the interface
SingletonRole from SingletonWrapper and change your clients to depend
on SingletonRole instead of Singleton.

constructor MyClient() {
    this(new SingletonWrapper(Singleton.getInstance()));
}

constructor MyClient(SingletonRole role) {
    this.role = role;
}

Production classes that use MyClient don't notice the change, but you
get to substitute SingletonRole's behavior in your tests.
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice
(Continue reading)

Permalink | Reply | 2 comments |
headers
J. B. Rainsberger | 5 May 2009 08:14
Picon

Re: Naming and grouping tests

On Tue, Apr 28, 2009 at 11:42 AM, Kaleb Pederson
<kaleb.pederson <at> gmail.com> wrote:

> This morning as I was pondering Keith Braithwaite's "TDD As If You
> Meant It"
> (http://www.parlezuml.com/softwarecraftsmanship/sessions/tdd_as_if_you_meant_it.htm)
> and I realized that I always name my tests based on the class that I
> think is going to satisfy the resultant test.
>
> This seems to be less than ideal for a couple of reasons, first, it
> presupposes that I know something about the design and, therefore,
> implies that I'm not letting the tests drive the design as well as I
> should. Second, it seems to create an artificial center for my tests
> -- it would be hard for a new employee to come in and know where a
> test would be for a certain behavior (unless I happen to have done a
> really good job naming the class and keeping classes at a single
> responsibility, which I'm still trying to perfect).
>
> So how should I name or group my tests? Should they be grouped based
> on behavior rather than by class name (i.e. responsibility) or is that
> ultimately the same thing when done "correctly." What works well for
> you?

I name my tests for the behavior I'm testing. In my classic "Fraction"
demo, I start with a test class named AddFractionsTest. When I truly
test the limits of design driven by my tests, I don't need a Fraction
class until I've written at least 3 or 4 tests.

If you have tests already organized by class, then use these simple
rules to rearrange them.
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. B. Rainsberger | 5 May 2009 08:16
Picon

Re: Do u have ideas of sketch of your program before you start TDD?

On Mon, Apr 27, 2009 at 2:35 AM, ablmf <ablmf <at> yahoo.com.cn> wrote:

> I've read "Test-Drive Development by Example". The author starts it's
> example from nothing but several requirements.
>
> But in real word, before you start TDD, don't you really have a rough idea
> of the sketch of the program you are going to write?

I have lived my entire life in the real world, and sometimes I don't
know how I'm going to design something until I start designing it.
It's more important to be able to design from scratch than it is to
design from scratch all the time.

> If for you, the answer is "YES", then how clear will the sketch be?
>
> A UML diagram contains only class relation-ship? Classes with interface
> names? Or classes with all interface clearly defined?

When I think I know what I want to design, I usually know the layers I
need to touch and that's enough for me to get started.
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

------------------------------------

Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lior Friedman | 5 May 2009 09:26
Picon

RE: Singleton problem

J. B. (Joe) Rainsberger wrote:

>> The problem with this is that you have to make changes to the
>> Singleton and I am not a permitted to do that.
>> I am stuck with this module of the system.
>>
>> This pattern is really nice, and it would be nice if I could use it
>> but as it is right now its not possible.

>You can also introduce a new class, SingletonWrapper that delegates
>its methods to the Singleton. From there, extract the interface
>SingletonRole from SingletonWrapper and change your clients to depend
>on SingletonRole instead of Singleton.

>constructor MyClient() {
>this(new SingletonWrapper(Singleton.getInstance()));
>}

>constructor MyClient(SingletonRole role) {
>this.role = role;
>}

>Production classes that use MyClient don't notice the change, but you
>get to substitute SingletonRole's behavior in your tests.

Another alternative is to just pick up a one of those mocking framework that
are able to mock static method .

Using that you'll be able to stub out the singleton pattern without the need
to go into the production code and change it.
(Continue reading)

Permalink | Reply | 1 comment |
headers
chris Burgess | 6 May 2009 20:58
Picon

Multiple similar tests for a single function - where do they go?

New guy TDDing w/nunit 2.5.

Let's say I want to write a function that validates an email address
with a regex. I write a little test to check my function and write the
actual function. Make it pass.

However, I can come up with a bunch of different ways to test the same
function (test <at> test.com; test234 <at> test.com; test.test.com, etc).

Do I put all the incantations that I need to check in the same, single
test with several ASSERTS or do I write a new test for every single
thing I can think of?

Thanks!

Chris

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)
(Continue reading)

Permalink | Reply | 7 comments |
headers
chris Burgess | 6 May 2009 22:27
Picon

Re: Multiple similar tests for a single function - where do they go?

Just found the ValuesAttribute goodness. Very cool!!

On Wed, May 6, 2009 at 2:58 PM, chris Burgess <cbtechlists <at> gmail.com> wrote:
> New guy TDDing w/nunit 2.5.
>
> Let's say I want to write a function that validates an email address
> with a regex. I write a little test to check my function and write the
> actual function. Make it pass.
>
> However, I can come up with a bunch of different ways to test the same
> function (test <at> test.com; test234 <at> test.com; test.test.com, etc).
>
> Do I put all the incantations that I need to check in the same, single
> test with several ASSERTS or do I write a new test for every single
> thing I can think of?
>
> Thanks!
>
> Chris
>

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dale Emery | 7 May 2009 00:34
Favicon
Gravatar

Re: Multiple similar tests for a single function - where do they go?

Hi Chris,

> Do I put all the incantations that I need to check in the same, single test
> with several ASSERTS or do I write a new test for every single thing I can
> think of?

For me the choice usually involves answers to two key questions.

If an assertion fails, would subsequent assertions give me information that
can help me locate the fault in the code?  If so, I want to separate the
assertions into separate tests.  That way, each assertion can pass or fail
independently of the others.  If, on the other hand, later assertions would
be either unhelpful or noise, I'll want to group those assertions into a
single test.

Second, does each assertion inform me about something I consider to be a
separate design decision?  If so, I'll want to separate the assertions into
separate tests.  That way, I can name each test method so that it concisely
describes the design decision.  I want of my design decisions to be
represented as test method names.  I don't want to have to look elsewhere,
such as at specific assertion methods.

In the vast majority of cases, my answers to one or both of these questions
leads me to write test methods with a single assertion each.  Every now and
then I'll write multiple assertions in a test method; usually when I'm
testing a series of states that I can't (yet) control individually.

Dale

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Donaldson, John (GEO | 7 May 2009 07:09
Picon
Favicon

RE: Multiple similar tests for a single function - where do they go?

Chris,

A tdd-question: do these extra cases you want to add create a failing test - one that forces you to write new
code to go green? If yes, then put them in a separate test. If they are just a belt-and-braces approach -
everything is green before and after - then put them in the same test.

Remember the red-green-refactor mantra - it sounds as though you are adding tests but everything stays
green. It's ok to do this, but normally you want to drive your code forward, and a green test doesn't do this.

John D.

-----Original Message-----
From: testdrivendevelopment <at> yahoogroups.com [mailto:testdrivendevelopment <at> yahoogroups.com] On
Behalf Of chris Burgess
Sent: 06 May 2009 20:59
To: testdrivendevelopment <at> yahoogroups.com
Subject: [TDD] Multiple similar tests for a single function - where do they go?

New guy TDDing w/nunit 2.5.

Let's say I want to write a function that validates an email address
with a regex. I write a little test to check my function and write the
actual function. Make it pass.

However, I can come up with a bunch of different ways to test the same
function (test <at> test.com; test234 <at> test.com; test.test.com, etc).

Do I put all the incantations that I need to check in the same, single
test with several ASSERTS or do I write a new test for every single
thing I can think of?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joshua Kerievsky | 7 May 2009 13:24

Re: Multiple similar tests for a single function - where do they go?

On Wed, May 6, 2009 at 11:58 AM, chris Burgess <cbtechlists <at> gmail.com>wrote:

> New guy TDDing w/nunit 2.5.

Excellent.  Are you also using any automated refactoring tools, like
Resharper?

>
>  Let's say I want to write a function that validates an email address
> with a regex. I write a little test to check my function and write the
> actual function. Make it pass.
>
> However, I can come up with a bunch of different ways to test the same
> function (test <at> test.com; test234 <at> test.com; test.test.com, etc).

You would likely explain "test.test.com" as an email address without an  <at> .
 That would very likely lead you to write a separate test method, so you can
ensure that your code correctly rejects any email example that is missing
the  <at>  sign.

> Do I put all the incantations that I need to check in the same, single
> test with several ASSERTS or do I write a new test for every single
> thing I can think of?

Your tests form your executable documentation, so produce tests that make it
easy to understand what you consider to be valid or invalid email addresses.

--

-- 
best regards,
jk
(Continue reading)

Permalink | Reply | 1 comment |

Gmane