Re: establishing logical test order?

"Pigneri, Rocco" <[email protected]> Tue, 24 Jun 2008 12:03:19 -0400
Newsgroups gmane.comp.windows.dotnet.nunit.user
Message-ID <D04B62A56C65EA4B860036108BD0A66C0258EC93@boston-ex.lavastorm.local.com>
Ah, I see what you are asking for now.  I have been in your situation
before.

In my situation, I had a standard three-tier architecture separated into
assemblies for each layer.  Each layer assembly had a test assembly that
tested it and the layers below it (much like yours, it sounds like).

I found that this organization worked well for me--especially when
refactoring across layers--in that I could easily identify the source of
an error by looking at the lowest layer that had a failure.  The
architecture led to a very "linear" organization in which it was very
easy for the developers to see that class A depended upon class B which
depended upon class C, etc.  Granted, this organization requires an
architecture suitable for TDD so this solution may not be appropriate
for you.

Rocco

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of David
Jeske
Sent: Tuesday, June 24, 2008 7:07 AM
To: Butler, Tony (London)
Cc: [email protected]
Subject: Re: [Nunit-users] establishing logical test order?

On Tue, Jun 24, 2008 at 2:03 AM, Butler, Tony (London)
<[email protected]> wrote:
> Since you are already DI-aware and are not using it for the project 
> which prompted you to post here about ordering dependent tests then 
> presumably you deem DI not appropriate for this case, so we may as 
> well end the discussion here since it's turning into a DI-101 topic 
> instead of an nunit one.

Not sure what gave you that idea. I'm using DI all over the place.
When I say it's not appropriate for everything, I mean that for every
dependency outside a class that I mock out and DI, there are three to
five more that I don't. I'm with you on your mock mailserver,

I think this discussion is all doubly-moot, because the "upstream
dependencies" I was talking about in my original message are upstream
dependencies with simpler parts of my own code. I don't care about all
the downstream failures, since they are all caused by the upstream bug.
I'd rather just see the most upstream bug in my code (the lowest-level
code). That's why I order everything from simplest-to-most-complicated
in order of dependencies.

While this is a little degenerate about DI, it's helpful to me to know
how people solve these problems with NUnit... When you have a bunch of
tests, and you want to make sure you can find the simplest and earliest
test that caused a problem (so you can fix that first), how do you do
it?

I use naming conventions to order the test results display (I don't care
about execution order)... You can see an example in the screenshot
attached..


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php