Re: Obfuscation & unit testing

"Brad Stiles" <[email protected]>
Newsgroups gmane.comp.windows.dotnet.nunit.user
Message-ID <[email protected]>
Charlie Poole <[email protected]> wrote:

> Hi Brad,
>
>>> This is actually a new argument for something I have talked about
>>> before: don't do acceptance tests in NUnit.
>>
>> I'm just starting to set up a FitNesse server now, so maybe
>> that will lead me to agree with you, but I'm curious, what
>> leads you to say this?  I've used it for that task, with some 
>> success.
>
> I've also done it when I had to, with "some" success. It's
> just not as good as it could be, IMO, for several reasons.

Well, you know what they say about only having a hammer...

> 1) Acceptance/Customer tests are supposed to be understandable
> by the customer.

Well, I haven't yet gotten into really involved user tests; our codebase 
won't support those anyway, it's so convoluted.  The ones I've done so 
far are pretty simple, being applied to some new code that I can get 
away with doing TDD on. :)  More involved ones, which would likely kick 
the "too complicated for users" filter, will hopefully be imlemented as 
FIT tests (or whatever might be appropriate; FIT/FitNesse was one I'd 
heard and read good things about, so it gets to be first).

> 2) The exercise of sitting with a customer to define and
> refine a FIT test is so valuable that it the interaction
> suddenly became unnecessary due to advances in technology,
> we would have to invent another reason to do it.

> 4) Changing to a different tool helps programmers to change
> their mindset - which they should do when they are working
> on customer tests.

I find these potentially some of the most compelling reasons in your 
list.


> 3) In some domains, tests need to be transparent, in the sense
> that given enough time one could take manually verify that the
> inputs match the outputs. Even where this is not required, I
> have found that customers tend to like this approach. FIT
> allows me to set up a display in that fashion.

I like the idea that if the user finds some edge case in an existing 
test, they can test it themselves without bothering me unless it doesn't 
work. :)  And although the FitNesse documentation has been somewhat 
difficult for me to understand, I've found enough guides and examples 
(the one from Gojko Adzic being especially helpful), that clarify things 
for me that I think I can teach people who want to add their own test 
scenarios.

I think one of the biggest advantages for me is that something like 
FIT/FitNesse is going to let me test the seams between my different 
layers without resorting to extraordinary measures trying to mock out 
things like databases and such.

> * I know you'll ask me for an example. :-) Here's one:
> There are APIs in .NET which only work in the primary
> AppDomain. NUnit runs tests in a secondary AppDomain.
> Q.E.D.

Actually, I was thinking of examples as I read your note. :)

Thanks for the response,
Brad 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.