Edwin Gabriel Castro wrote:
> All good points.
>
> How did you determine you needed a facade? How did you determine the
> interfaces to the "work-horse" classes? It sounds to me like you have
> already designed the system. At this point I don't feel like you are doing
> TDD anymore. You are testing. Put your tests where they make sense.

Edwin,

I'm still pretty sure I'm writing my code test first. I don't have a
design on paper for what I'm writing, I'm writing tests before I write
code, and I'm eliminating duplication after each test. If I'm missing
something, please let me know.

What I am doing, however, is conforming to the requirements that I have.
We're building a library, so the interface is pretty important. The
domain experts have told us how clients will use our library, based on
client feedback and their own experiences, but we are completely free to
implement anything we want under the covers. We just have to do our best
to make the given interface work.

Does that mean that I can't do TDD? Certainly not. It just means that my
interface to the world is fixed. On larger teams this happens all the
time, and in one sense, I'm writing software for a team that numbers in
the tens of thousands (think world's largest software company).

>
> If I was TDD a system I would begin TDD the classes as public since my tests
> need access to them and my tests reflect "user" usage. At a later point I
> decide the system has become to difficult to use and decide to use a facade
> to simplify it I would begin at that point by adding another public
> interface (the facade), writing the tests first reflecting the new "user"
> usage. If prior to release you need to restrict the end user from accessing
> the "work-horse" classes then you make them internal (in a .NET environment)
> and at that point decide how to update your tests so that you can still use
> them during maintanance. In TDD (and in agile methods in general) you want
> to make decsions as late as possible. If you are running into problems about
> where tests should be at an early stage of the game then you are making too
> many descisions.

I understand and appreciate how you would do this. I, in fact, have
developed code like this many times. But part of gaining mastery over
any of the agile practices is that you're allowed to start modifying it
to suit your own purposes better. I'm working on a team with two other
TDD masters, and we're led by the guy who wrote NUnit. Given our
circumstances, and the overriding need to keep our API as simple and
unpolluted by implementation details as possible, it is essential for us
to keep certain classes internal. And it is obvious to us which classes
those are. During our own development, we have certainly had cases where
classes that we originally thought were going to be strictly internal
turned out to need to be public, and we changed them. No big deal.

But we are still hiding most of our implementation classes by making
them internal.

I'd appreciate your opinion on how we're missing the TDD boat. I can
always get better...

bab

--
Brian Button  bbutton@...
Principal Consultant http://www.agilesolutionsgroup.com
Agile Solutions Group http://dotnetjunkies.com/weblog/oneagilecoder
St. Louis, MO  636.399.3146

Extreme Programming in St Louis - http://groups.yahoo.com/group/xpstl


[Non-text portions of this message have been removed]

I think we all misunderstood our messages. (There's that darn communication
problem again!)

As usual, more information clears things up.

Agile is about having the ability to reactly quickly (almost instantly) to
change. The question is whether the decisions you make now will be impacted
by changes down the road. If your team can handle future changes
(unpredictable by definition) in an agile manner (quickly, efficiently, etc)
then your method works.

I personally believe (in the case of libraries) that tests should verify
specifications (ie, promises made by interfaces). The authors of C++ FAQs
contrast proper and improper inheritance. Proper inheritance is a really
cool concept; actually, it's almost too obvious but I see people making the
mistake often. Oh, when I talk about interfaces I mean in a general sense
rather than in a .NET specific sense.

I suppose the internal problem here is very much so .NET specific. The
closest thing Java has is the so-called "default" access modifier (no
modifier at all) which allows package access which more like namespace
access in .NET. The closest thing C++ has is friend and that's specified at
an artifact by artifact basis.

I believe, personal opinion, that many "neat" features of .NET (like
internal) are residual from COM, usually make things more complex, and cause
developers to think way too much. They are well intended and have purpose
(otherwise, they wouldn't exist), but for the most part they should be used
sparingly.

That said, I think using internal for encapsulation purposes can be very
useful. As I said in a different email, I like to keep my tests close to the
classes they test. Something like the following in .NET:

namespace A
{
#if Test
     namespace Test
     {
         /* Test class */
     }
#endif

     /* Class */
}

That allows me to keep my tests close to the thing I'm testing (as a
cohesive unit), no questions about accessibility, and allows me to remove
the tests by not defining the #define Test.

In the end I think we were disagreeing on the interpretation of philosophy
rather than anything else. From your descriptions you definitely follow TDD
as closely as your implementation environment allows you to. Because of that
I appologize for my previous rudeness. No one deserves that.


(World's largest software company, eh? Must be a hardcore Linux programmer
switching over to Mono! Just a joke! :-)

----- Original Message -----
From: "Brian Button" <bbutton@...>
To: <testdrivendevelopment@yahoogroups.com>
Sent: Friday, October 01, 2004 6:28 AM
Subject: Re: [TDD] Re: Where to put test code


> Edwin Gabriel Castro wrote:
>> All good points.
>>
>> How did you determine you needed a facade? How did you determine the
>> interfaces to the "work-horse" classes? It sounds to me like you have
>> already designed the system. At this point I don't feel like you are
>> doing
>> TDD anymore. You are testing. Put your tests where they make sense.
>
> Edwin,
>
> I'm still pretty sure I'm writing my code test first. I don't have a
> design on paper for what I'm writing, I'm writing tests before I write
> code, and I'm eliminating duplication after each test. If I'm missing
> something, please let me know.
>
> What I am doing, however, is conforming to the requirements that I have.
> We're building a library, so the interface is pretty important. The
> domain experts have told us how clients will use our library, based on
> client feedback and their own experiences, but we are completely free to
> implement anything we want under the covers. We just have to do our best
> to make the given interface work.
>
> Does that mean that I can't do TDD? Certainly not. It just means that my
> interface to the world is fixed. On larger teams this happens all the
> time, and in one sense, I'm writing software for a team that numbers in
> the tens of thousands (think world's largest software company).
>
>>
>> If I was TDD a system I would begin TDD the classes as public since my
>> tests
>> need access to them and my tests reflect "user" usage. At a later point I
>> decide the system has become to difficult to use and decide to use a
>> facade
>> to simplify it I would begin at that point by adding another public
>> interface (the facade), writing the tests first reflecting the new "user"
>> usage. If prior to release you need to restrict the end user from
>> accessing
>> the "work-horse" classes then you make them internal (in a .NET
>> environment)
>> and at that point decide how to update your tests so that you can still
>> use
>> them during maintanance. In TDD (and in agile methods in general) you
>> want
>> to make decsions as late as possible. If you are running into problems
>> about
>> where tests should be at an early stage of the game then you are making
>> too
>> many descisions.
>
> I understand and appreciate how you would do this. I, in fact, have
> developed code like this many times. But part of gaining mastery over
> any of the agile practices is that you're allowed to start modifying it
> to suit your own purposes better. I'm working on a team with two other
> TDD masters, and we're led by the guy who wrote NUnit. Given our
> circumstances, and the overriding need to keep our API as simple and
> unpolluted by implementation details as possible, it is essential for us
> to keep certain classes internal. And it is obvious to us which classes
> those are. During our own development, we have certainly had cases where
> classes that we originally thought were going to be strictly internal
> turned out to need to be public, and we changed them. No big deal.
>
> But we are still hiding most of our implementation classes by making
> them internal.
>
> I'd appreciate your opinion on how we're missing the TDD boat. I can
> always get better...
>
> bab
>
> --
> Brian Button bbutton@...
> Principal Consultant http://www.agilesolutionsgroup.com
> Agile Solutions Group http://dotnetjunkies.com/weblog/oneagilecoder
> St. Louis, MO 636.399.3146
>
> Extreme Programming in St Louis - http://groups.yahoo.com/group/xpstl
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

Edwin Gabriel Castro wrote:

> In the end I think we were disagreeing on the interpretation of
> philosophy
> rather than anything else. From your descriptions you definitely
> follow TDD
> as closely as your implementation environment allows you to. Because
> of that
> I appologize for my previous rudeness. No one deserves that.
>
>
> (World's largest software company, eh? Must be a hardcore Linux
> programmer
> switching over to Mono! Just a joke! :-)


Well, Brian's not going to toot his own horn on this one, but he's been
doing TDD longer than about 99% of the developers who've tried it.  He's
trained people in it for years, he's one of the best developers I know
and he's worked with some of the best developers I've ever met.

Michael (that was just a compensatory toot.. something the conversation
needed)

On Fri, Oct 01, 2004 at 09:06:20AM -0700, Edwin Gabriel Castro wrote:
>
> I personally believe (in the case of libraries) that tests should verify
> specifications (ie, promises made by interfaces).

Would not that be called an Acceptance Test?

  - George

Edwin Gabriel Castro wrote:

> In the end I think we were disagreeing on the interpretation of philosophy
> rather than anything else. From your descriptions you definitely follow TDD
> as closely as your implementation environment allows you to. Because of that
> I appologize for my previous rudeness. No one deserves that.

Edwin,

No harm, no foul. If we didn't feel passionate about this stuff, we
wouldn't argue about it :)

>
> (World's largest software company, eh? Must be a hardcore Linux programmer
> switching over to Mono! Just a joke! :-)

Actually, long-time Linux user who recently swallowed the orange pill...
(blue pill == blue badge == employee), (orange pill == consultant)

bab

--
Brian Button  bbutton@...
Principal Consultant http://www.agilesolutionsgroup.com
Agile Solutions Group http://dotnetjunkies.com/weblog/oneagilecoder
St. Louis, MO  636.399.3146

Extreme Programming in St Louis - http://groups.yahoo.com/group/xpstl


[Non-text portions of this message have been removed]

I am about to embark on refactoring an existing J2EE application at work.
The current application has a simple data access object that returns various
objects queried from a DB2 database.  There are unit tests associated with
this code now but they query against a development instance of the database
and assume that certain data already exists in the database.  What approaches
have others taken when writing unit tests for DAOs?


--
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomse by it"
     - Jon Ruskin

Jeff Morgan wrote:
>
> I am about to embark on refactoring an existing J2EE application at work.
> The current application has a simple data access object that returns various
> objects queried from a DB2 database.  There are unit tests associated with
> this code now but they query against a development instance of the database
> and assume that certain data already exists in the database.  What approaches
> have others taken when writing unit tests for DAOs?

If you aren't offending by a book recommendation, chapter 10 of _JUnit
Recipes_ can tell you lots. :)

The short version is this: if you just test that your DAOs round trip
data correctly, you'll have tests that are repetitive and slow. Instead,
look for how to extract executing the JDBC commands into reusable code.
Extract Interface. Now your DAOs can depend on an interface that's
simpler than JDBC and easier to mock/fake.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Predictable, repeatable, quality delivery

I use dbUnit.

On Fri, Oct 01, 2004 at 09:18:49AM -0400, Jeff Morgan wrote:
>
>
> I am about to embark on refactoring an existing J2EE application at work.
> The current application has a simple data access object that returns various
> objects queried from a DB2 database.  There are unit tests associated with
> this code now but they query against a development instance of the database
> and assume that certain data already exists in the database.  What approaches
> have others taken when writing unit tests for DAOs?

I tend to think of acceptance tests as "system-wide" functional tests
representing user stories (use cases). The end user (or a representative) of
the entire system would then write the acceptance tests capturing all of the
requirements (use cases).

I like to think of unit tests as acceptance tests for units (classes,
modules, what have you). In that sense the tests should reflect how that
unit is to be used (interface) and how the unit should respond
(specification). In this perspective, the end users of the unit are the
other developers of the entire system (in multi-developer environments).

I cringe every time I hear people wanting to test internals (not the .NET
keyword :-) because code should not be written unless there is a test for it
first. If the test truly exists first then the test is written from the
perspective of the "user" (some other developer). The purpose of
encapsulation is to decouple interface and specification from
implementation. When the test is written with the purpose to test the
internals I feel that encapsulation is braking at some point. If the test
represents the interface and specification of the unit, then you are
verifying that the unit behaves according to specification regardless of the
implementation and encapsulation is maintained.

I expect most of the misunderstandings due to my original post are due to
inconsistent use of terminology. Terminology can be a dangerous thing. I
can't remember a single role playing session where the game master and at
least one player did not get into an argument due to different
interpretations of the same term (or perhaps the interpretation was
equivalent but the terms used to describe the interpretation meant different
things to different people).

Sorry, that was a little off-topic, but I thought the two situations were
strikingly similar and could help as an example.

----- Original Message -----
From: "George Dinwiddie" <programminglists@...>
To: <testdrivendevelopment@yahoogroups.com>
Sent: Friday, October 01, 2004 11:18 AM
Subject: Re: [TDD] Re: Where to put test code


> On Fri, Oct 01, 2004 at 09:06:20AM -0700, Edwin Gabriel Castro wrote:
>>
>> I personally believe (in the case of libraries) that tests should verify
>> specifications (ie, promises made by interfaces).
>
> Would not that be called an Acceptance Test?
>
> - George
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

I was wondering what people knew about this project.  Is it in use?
Are there examples and assemblies to use?  Thank you.

Carlton

With your permission – here's something I posted on my blog just now and thought
this may be a valuable addition to Nunit in some way.

(published here:
http://weblogs.asp.net/rosherove/archive/2004/10/05/238201.aspx)  your feedback
is welcome.



Introducing: unofficial NUnit Extensibility Framework - make your own test
attributes easily!
<http://weblogs.asp.net/rosherove/archive/2004/10/05/238201.aspx>

One of the things that have bothered me the most since I got into the whole "Add
database rollback to your unit tests" thing, is how much work it takes to make
your test suite use this feature. I actually went and made a new binary of the
NUnit Framework to support this new attribute. All this because there is no
clear extensibility model for NUnit these days. Peli, on the other hand has a
very nice way of extending MbUnit, but it still entails recompiling his library
for this to work (or am I wrong?)

so - an idea came to me. A while ago Peli <http://blog.dotnetwiki.org/> told me
he had just found out about ContextBoundObjects and the ability to "intercept"
method calls for pre and post processing. He said it might have some cool things
that can be used with unit testing but we couldn't find something that was
really cool to do with it.

The other day, while reading this nice article
<http://www.codeproject.com/csharp/AspectIntercept.asp> about implementing
interception in your code, I got an idea: Maybe interception and Contexts are
the best way for extensibility? So, I gave it a shot. And it turns out pretty
darn cool I have to say.

Introducing the NUnit.Extensions.ExtensibilityFramework project

With this project you are now able to add any attribute you can think of to you
NUnit (or any other xUnit tests) with the ease of simply deriving from a base
class. In the solution that you can download you will find 3 projects:

- The Extensibility framework base classes (2 of them - one to derive your test
fixtures from, and one if you want to create your own attributes)

- Nunit.Extensions.Royo is a project that I made that uses these bases classes
to add two attributes. The the now known [Rollback] attribute, and the second
one is a simple [Tracing] Attribute. You can see the code and realize how simple
it really is.

- a sample project with one simple fixture that uses the custom attributes.

now here are the cool things:

- You can now *fully* debug and step into your tests, and the [Rollback]
attribute works perfectly!

- You are not depending on any specific framework! Simply compile the
NUnit.tExtensionsFramework project with your Testing framework of choice and
that's that! no more NunitX variants, thank god! Yes. This means you can use
your existing NUnit 2.x projects with these attributes and even add your won.
Just add these two projects to your solution and you're done.

-It is very easy to create your own attributes

Download the zip file here
<http://www.osherove.com/downloads/ExtensibleNunit.zip>

I'd love to get your feedback. Have fun :)

I'd like to thank Jamie <http://weblogs.asp.net/nunitaddin>  for helping me
solve two simple and annoying bugs I just couldn't find with my  think head.



Thanks,

Roy Osherove

www.iserializable.com <http://www.iserializable.com/>





[Non-text portions of this message have been removed]

Hi,

I've got a weird problem with Nunit and it boils down to
the code below. It seems that Asserts in methods on ThreadPool
threads don't work (if you step through with the debugger
the failing assert is caught but not otherwise). I was trying
to make my test fail, and it just kept on passing!

Is this a known limitation?

John D.

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

Here's the example:

		 private int _mainThreadId;

		 [SetUp]
		 public void SetUp()
		 {
			 _mainThreadId =
System.AppDomain.GetCurrentThreadId();
		 }

		 private int _WCBTargetThreadId = 0;

		 private void WCBTarget( object stateInfo)
		 {
			 _WCBTargetThreadId =
System.AppDomain.GetCurrentThreadId();
			 // very odd - the next two statements are
logical opposites - can't both be true
			 Assert.IsTrue( _mainThreadId !=
_WCBTargetThreadId, "Expected a different thread id");
			 Assert.IsFalse( _mainThreadId !=
_WCBTargetThreadId, "Very odd - shouldn't pass");
		 }

		 [Test]
		 public void QueueUserWorkItem()
		 {
			 WaitCallback wcb = new WaitCallback( WCBTarget);
			 Assert.IsTrue( ThreadPool.QueueUserWorkItem(
wcb), "Expected to queue the work");
			 System.Threading.Thread.Sleep( 100);
			 Console.WriteLine( "_WCBTargetThreadId = {0},
_mainThreadId = {1}", _WCBTargetThreadId, _mainThreadId);
			 Assert.IsTrue( _mainThreadId !=
_WCBTargetThreadId, "Expected the work to be running on a different
thread to the work queuer");
		 }

Donaldson, John (GEO) wrote:
>
> Hi,
>
> I've got a weird problem with Nunit and it boils down to
> the code below. It seems that Asserts in methods on ThreadPool
> threads don't work (if you step through with the debugger
> the failing assert is caught but not otherwise). I was trying
> to make my test fail, and it just kept on passing!
>
> Is this a known limitation?

I looked at your code, and I think I understand what is happening. Which
version of NUnit are you using? I've heard rumors that 2.2 solves this
problem, but in 2.1 and before, exceptions thrown on other threads have
no effect on the passing or failing of your tests. You have to somehow
get the information about the failure from the other thread back to the
test thread and do an assert there if you want a test to fail because of it.

Could that be your problem?

bab

--
Brian Button  bbutton@...
Principal Consultant http://www.agilesolutionsgroup.com
Agile Solutions Group http://dotnetjunkies.com/weblog/oneagilecoder
St. Louis, MO  636.399.3146

Extreme Programming in St Louis - http://groups.yahoo.com/group/xpstl


[Non-text portions of this message have been removed]

John,

Yes - Brian is right.  It appears to be due to the exception occurring on
another thread.  Trapping the exception and then checking it, yields the
expected result - code below.  I tested the below in 2.1 but not 2.2.

Regards,
Jonathan Cogley [MVP C#]
http://weblogs.asp.net/jcogley

private int _mainThreadId;

[SetUp]
public void SetUp()
{
	 _mainThreadId =
		 System.AppDomain.GetCurrentThreadId();
}

private int _WCBTargetThreadId = 0;
private Exception _lastException = null;
private void WCBTarget( object stateInfo)
{
	 try
	 {
		 _WCBTargetThreadId =
			 System.AppDomain.GetCurrentThreadId();
		 // very odd - the next two statements are logical opposites
- can't both be true
		 Assert.IsTrue( _mainThreadId !=
			 _WCBTargetThreadId, "Expected a different thread
id");
		 Assert.IsFalse( _mainThreadId !=
			 _WCBTargetThreadId, "Very odd - shouldn't pass");
	 }
	 catch (Exception e)
	 {
		 _lastException = e;
	 }
}

[Test]
public void QueueUserWorkItem()
{
	 WaitCallback wcb = new WaitCallback( WCBTarget);
	 Assert.IsTrue( ThreadPool.QueueUserWorkItem( wcb), "Expected to
queue the work");
	 System.Threading.Thread.Sleep( 100);
	 Console.WriteLine( "_WCBTargetThreadId = {0}, _mainThreadId = {1}",
_WCBTargetThreadId, _mainThreadId);
	 Assert.IsTrue( _mainThreadId !=
		 _WCBTargetThreadId, "Expected the work to be running on a
different thread to the work queuer");
	 if (_lastException != null)
	 {
		 throw _lastException;
	 }
}
-----Original Message-----
From: Brian Button [mailto:bbutton@...]
Sent: Wednesday, October 06, 2004 6:04 PM
To: testdrivendevelopment@yahoogroups.com
Subject: Re: [TDD] ThreadPool limitation?


Donaldson, John (GEO) wrote:
>
> Hi,
>
> I've got a weird problem with Nunit and it boils down to
> the code below. It seems that Asserts in methods on ThreadPool
> threads don't work (if you step through with the debugger
> the failing assert is caught but not otherwise). I was trying
> to make my test fail, and it just kept on passing!
>
> Is this a known limitation?

I looked at your code, and I think I understand what is happening. Which
version of NUnit are you using? I've heard rumors that 2.2 solves this
problem, but in 2.1 and before, exceptions thrown on other threads have
no effect on the passing or failing of your tests. You have to somehow
get the information about the failure from the other thread back to the
test thread and do an assert there if you want a test to fail because of it.

Could that be your problem?

bab

--
Brian Button  bbutton@...
Principal Consultant http://www.agilesolutionsgroup.com
Agile Solutions Group http://dotnetjunkies.com/weblog/oneagilecoder
St. Louis, MO  636.399.3146

Extreme Programming in St Louis - http://groups.yahoo.com/group/xpstl


[Non-text portions of this message have been removed]





Yahoo! Groups Links

Thanks both. I'm currently using 2.1.4. I'll pick up the latest and try
to remember to post the result back here.

John D.

-----Original Message-----
From: Jonathan Cogley [mailto:jonathan@...]
Sent: Thursday, October 07, 2004 5:47 AM
To: testdrivendevelopment@yahoogroups.com
Subject: RE: [TDD] ThreadPool limitation?


John,

Yes - Brian is right.  It appears to be due to the exception occurring
on another thread.  Trapping the exception and then checking it, yields
the expected result - code below.  I tested the below in 2.1 but not
2.2.

Regards,
Jonathan Cogley [MVP C#]
http://weblogs.asp.net/jcogley

private int _mainThreadId;

[SetUp]
public void SetUp()
{
	 _mainThreadId =
		 System.AppDomain.GetCurrentThreadId();
}

private int _WCBTargetThreadId = 0;
private Exception _lastException = null; private void WCBTarget( object
stateInfo) {
	 try
	 {
		 _WCBTargetThreadId =
			 System.AppDomain.GetCurrentThreadId();
		 // very odd - the next two statements are logical
opposites
- can't both be true
		 Assert.IsTrue( _mainThreadId !=
			 _WCBTargetThreadId, "Expected a different thread
id");
		 Assert.IsFalse( _mainThreadId !=
			 _WCBTargetThreadId, "Very odd - shouldn't
pass");
	 }
	 catch (Exception e)
	 {
		 _lastException = e;
	 }
}

[Test]
public void QueueUserWorkItem()
{
	 WaitCallback wcb = new WaitCallback( WCBTarget);
	 Assert.IsTrue( ThreadPool.QueueUserWorkItem( wcb), "Expected to
queue the work");
	 System.Threading.Thread.Sleep( 100);
	 Console.WriteLine( "_WCBTargetThreadId = {0}, _mainThreadId =
{1}", _WCBTargetThreadId, _mainThreadId);
	 Assert.IsTrue( _mainThreadId !=
		 _WCBTargetThreadId, "Expected the work to be running on
a different thread to the work queuer");
	 if (_lastException != null)
	 {
		 throw _lastException;
	 }
}
-----Original Message-----
From: Brian Button [mailto:bbutton@...]
Sent: Wednesday, October 06, 2004 6:04 PM
To: testdrivendevelopment@yahoogroups.com
Subject: Re: [TDD] ThreadPool limitation?


Donaldson, John (GEO) wrote:
>
> Hi,
>
> I've got a weird problem with Nunit and it boils down to
> the code below. It seems that Asserts in methods on ThreadPool
> threads don't work (if you step through with the debugger
> the failing assert is caught but not otherwise). I was trying
> to make my test fail, and it just kept on passing!
>
> Is this a known limitation?

I looked at your code, and I think I understand what is happening. Which

version of NUnit are you using? I've heard rumors that 2.2 solves this
problem, but in 2.1 and before, exceptions thrown on other threads have
no effect on the passing or failing of your tests. You have to somehow
get the information about the failure from the other thread back to the
test thread and do an assert there if you want a test to fail because of
it.

Could that be your problem?

bab

--
Brian Button  bbutton@...
Principal Consultant http://www.agilesolutionsgroup.com
Agile Solutions Group http://dotnetjunkies.com/weblog/oneagilecoder
St. Louis, MO  636.399.3146

Extreme Programming in St Louis - http://groups.yahoo.com/group/xpstl


[Non-text portions of this message have been removed]





Yahoo! Groups Links












Yahoo! Groups Links

Well, I retried with v2.2, and the behaviour is slightly different.
Now, the routine on the threadpool thread is interrupted when the
Assert fails but the result is not reported on the Nunit GUI. So,
you still have to somehow pass the result back out of the worker
routine. For example, as Jonathan shows using an exception variable.

John D.

-----Original Message-----
From: Jonathan Cogley [mailto:jonathan@...]
Sent: Thursday, October 07, 2004 5:47 AM
To: testdrivendevelopment@yahoogroups.com
Subject: RE: [TDD] ThreadPool limitation?


John,

Yes - Brian is right.  It appears to be due to the exception occurring
on another thread.  Trapping the exception and then checking it, yields
the expected result - code below.  I tested the below in 2.1 but not
2.2.

Regards,
Jonathan Cogley [MVP C#]
http://weblogs.asp.net/jcogley

private int _mainThreadId;

[SetUp]
public void SetUp()
{
	 _mainThreadId =
		 System.AppDomain.GetCurrentThreadId();
}

private int _WCBTargetThreadId = 0;
private Exception _lastException = null; private void WCBTarget( object
stateInfo) {
	 try
	 {
		 _WCBTargetThreadId =
			 System.AppDomain.GetCurrentThreadId();
		 // very odd - the next two statements are logical
opposites
- can't both be true
		 Assert.IsTrue( _mainThreadId !=
			 _WCBTargetThreadId, "Expected a different thread
id");
		 Assert.IsFalse( _mainThreadId !=
			 _WCBTargetThreadId, "Very odd - shouldn't
pass");
	 }
	 catch (Exception e)
	 {
		 _lastException = e;
	 }
}

[Test]
public void QueueUserWorkItem()
{
	 WaitCallback wcb = new WaitCallback( WCBTarget);
	 Assert.IsTrue( ThreadPool.QueueUserWorkItem( wcb), "Expected to
queue the work");
	 System.Threading.Thread.Sleep( 100);
	 Console.WriteLine( "_WCBTargetThreadId = {0}, _mainThreadId =
{1}", _WCBTargetThreadId, _mainThreadId);
	 Assert.IsTrue( _mainThreadId !=
		 _WCBTargetThreadId, "Expected the work to be running on
a different thread to the work queuer");
	 if (_lastException != null)
	 {
		 throw _lastException;
	 }
}
-----Original Message-----
From: Brian Button [mailto:bbutton@...]
Sent: Wednesday, October 06, 2004 6:04 PM
To: testdrivendevelopment@yahoogroups.com
Subject: Re: [TDD] ThreadPool limitation?


Donaldson, John (GEO) wrote:
>
> Hi,
>
> I've got a weird problem with Nunit and it boils down to
> the code below. It seems that Asserts in methods on ThreadPool
> threads don't work (if you step through with the debugger
> the failing assert is caught but not otherwise). I was trying
> to make my test fail, and it just kept on passing!
>
> Is this a known limitation?

I looked at your code, and I think I understand what is happening. Which

version of NUnit are you using? I've heard rumors that 2.2 solves this
problem, but in 2.1 and before, exceptions thrown on other threads have
no effect on the passing or failing of your tests. You have to somehow
get the information about the failure from the other thread back to the
test thread and do an assert there if you want a test to fail because of
it.

Could that be your problem?

bab

--
Brian Button  bbutton@...
Principal Consultant http://www.agilesolutionsgroup.com
Agile Solutions Group http://dotnetjunkies.com/weblog/oneagilecoder
St. Louis, MO  636.399.3146

Extreme Programming in St Louis - http://groups.yahoo.com/group/xpstl


[Non-text portions of this message have been removed]





Yahoo! Groups Links












Yahoo! Groups Links

This bit of TDD magic brought to you by the Ruby-Talk mailing list via
John Long of the Chicago Ruby Users Group. Pass a simple, empty
Functor object in to the method under test, and it does your bidding,
which you specified in a locally-scoped code block at Functor creation
time.

You don't even have to use instance variables on the spy object, since
it uses local variables in the test method.

This could even be extended to log the method calls to the Functor
with their arguments, or whatever testing pattern you want to apply.

=====

Given the following definition of a Functor:

    class Functor
      def initialize(&func)
        @func = func
      end
      def method_missing(op, *args)
        @func.call(op, *args)
      end
    end

Pretend I have a method called redirect that I am trying to test:

    def redirect(url, sys=Kernel)
      #
      # code here that writes out an HTTP header
      # that causes the redirect to url
      #

      # my header has been written so kill the script:
      sys.exit
    end

Here's my test method:

    def test_redirect__exit
      exited = false
      sys = Functor.new { |meth, *args|
        exited = true if meth == :exit
      }
      redirect('test/url.html', sys)
      assert(exited)
    end

Normally I would have created my own mock object instead and defined the
test method like so:

    def test_redirect__exit
      sys = Object.new
      def sys.exit
         @exited = true
      end
      def sys.exited?
         @exited || false
      end
      redirect('test/url.html', sys)
      assert(sys.exited?)
    end

Not nearly as clean. This example is admittedly contrived, but I think
it gives you an idea of how you could use a Functor as a Mock object.
I'm sure there are a ton of other uses, but this is what came to mind.

Pretty cool use of method_missing.

=====

--
Ryan Platte

Ryan Platte wrote:

> This bit of TDD magic brought to you by the Ruby-Talk mailing list via
> John Long of the Chicago Ruby Users Group. Pass a simple, empty
> Functor object in to the method under test, and it does your bidding,
> which you specified in a locally-scoped code block at Functor creation
> time.
<snip />

Now /this/ is programming. This is the stuff I miss by working in Java
and C#. This is the stuff I'd rather be doing. This is just neat.

>    def test_redirect__exit
>      exited = false
>      sys = Functor.new { |meth, *args|
>        exited = true if meth == :exit
>      }
>      redirect('test/url.html', sys)
>      assert(exited)
>    end

Very neat.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Predictable, repeatable, quality delivery

Ryan Platte wrote:

>
> This bit of TDD magic brought to you by the Ruby-Talk mailing list via
> John Long of the Chicago Ruby Users Group. Pass a simple, empty
> Functor object in to the method under test, and it does your bidding,
> which you specified in a locally-scoped code block at Functor creation
> time.
>
> You don't even have to use instance variables on the spy object, since
> it uses local variables in the test method.
>
> This could even be extended to log the method calls to the Functor
> with their arguments, or whatever testing pattern you want to apply.


That is very cool.  Ever try returning 'self' from the functor?  That
could be a  neat effect. :-)


Michael Feathers
www.objectmentor.com

Michael Feathers wrote:

> Ryan Platte wrote:
>
> >
> > This bit of TDD magic brought to you by the Ruby-Talk mailing list via
> > John Long of the Chicago Ruby Users Group. Pass a simple, empty
> > Functor object in to the method under test, and it does your bidding,
> > which you specified in a locally-scoped code block at Functor creation
> > time.
> >
> > You don't even have to use instance variables on the spy object, since
> > it uses local variables in the test method.
> >
> > This could even be extended to log the method calls to the Functor
> > with their arguments, or whatever testing pattern you want to apply.
>
>
> That is very cool.  Ever try returning 'self' from the functor?  That
> could be a  neat effect. :-)


Ooops..  I meant 'self' from 'method_missing.'

Does anyone know of a unit testing framework for RPG ILE?

I'm afraid this is wishful thinking, but it's worth a shot.

Thanks,
Keith Reichert

Joe,

I certainly like the idea of using mocks to test the DAOs.
It definitely simplifies the tests and makes then run a lot faster.

However, I am still a little uncomfortable with the idea of not
automating the tests for the SQL statements. For instance, changes to
the schema cause SQL statements to not 'compile' and simple mistakes
such as using a > instead of a >= can cause subtle bugs.

On the other hand, tests that access the database (even an in-memory
database) have a lot of overhead. Have you had any more thoughts on
the topic since writing your book? (which BTW is a great read).

Chris

PS.
On Sat, 02 Oct 2004 19:51:09 -0400, J. B. Rainsberger
<jbrains@...> wrote:
>
> Jeff Morgan wrote:
> >
> > I am about to embark on refactoring an existing J2EE application at work.
> > The current application has a simple data access object that returns various
> > objects queried from a DB2 database.  There are unit tests associated with
> > this code now but they query against a development instance of the database
> > and assume that certain data already exists in the database.  What
approaches
> > have others taken when writing unit tests for DAOs?
>
> If you aren't offending by a book recommendation, chapter 10 of _JUnit
> Recipes_ can tell you lots. :)
>
> The short version is this: if you just test that your DAOs round trip
> data correctly, you'll have tests that are repetitive and slow. Instead,
> look for how to extract executing the JDBC commands into reusable code.
> Extract Interface. Now your DAOs can depend on an interface that's
> simpler than JDBC and easier to mock/fake.
> --
> J. B. (Joe) Rainsberger
> Diaspar Software Services
> http://www.diasparsoftware.com :: +1 416 791-8603
> Predictable, repeatable, quality delivery
>
>

Thanks for J.B. for bringing to my attention this is
something I could use with what I'm doing now...
Thanks to Ryan and John for bringing it to us.

   I did this in Perl since I'm coding a lot in that
right now, and maybe this will be useful to others.

   I have to say that it's not as elegant, esp. the
class definition -- this way coz you do all the OO
implementation yourself (but I use emacs templates, so
I never have to type much), but the test function is
comparably concise.

   Apologies for any mistyping, where I read email is
not connected to where I code.

> =====
>
> Given the following definition of a Functor:
>
>    class Functor
>      def initialize(&func)
>        @func = func
>      end
>      def method_missing(op, *args)
>        @func.call(op, *args)
>      end
>    end
>

Perl:

package Functor;
use strict; # always
use vars qw ($AUTOLOAD); # need to to this for
method_missing equivalent
use Carp; # for croak

sub new { # the constructor, a somewhat std way of one
of many ways to do it.
   my $proto = shift;
   my $class = ref( $proto) || $proto; # support
various ways of calling it
   my $self = {
                func => shift;
              }; # internal representation as hash
   bless ($self, $class);
   return $self;
}

sub AUTOLOAD { #method_missing equivalent
   my $self = shift;
   my $type = ref( $self)
     or croak "$self is not an object"; # typical
checking for object instance
   my $method_name = $AUTOLOAD;
   $method_name =~ s/$type\:\://;
   &{$self->{func}}( $method_name, @_;
}
> Pretend I have a method called redirect that I am
> trying to test:
>
>    def redirect(url, sys=Kernel)
>      #
>      # code here that writes out an HTTP header
>      # that causes the redirect to url
>      #
>
>      # my header has been written so kill the
> script:
>      sys.exit
>    end
>

equivalent test method:

sub redirect ($$) {
   my ($file, $sys) = @_;  # yeah, yeah, we extract the
parameters manually
   # code to write out HTTP header...

   # exit now written
   $sys->exit();
}

> Here's my test method:
>
>    def test_redirect__exit
>      exited = false
>      sys = Functor.new { |meth, *args|
>        exited = true if meth == :exit
>      }
>      redirect('test/url.html', sys)
>      assert(exited)
>    end
>

equivalent test method:

sub testRedirectExit {
   my $exited = 0;
   my $sys = Functor->new(
                          sub { my $meth = shift;
                                $exited = 1 if $meth eq
"exit";
                               }
                          );
   redirect( "foo", $sys);
   ok( $exited);  # I frequently use the more
lightweight Test::More to TDD with
}

> Normally I would have created my own mock object
> instead and defined the
> test method like so:
>
>
   This part much more painful in Perl since it doesn't
have singleton methods, so I'm going to use my new
Functor class a lot now.

Forrest

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Chris Richardson wrote:

> However, I am still a little uncomfortable with the idea of not
> automating the tests for the SQL statements. For instance, changes to
> the schema cause SQL statements to not 'compile' and simple mistakes
> such as using a > instead of a >= can cause subtle bugs.

If you're worried about SQL statements not working against schema
changes, then add a smoke test suite that tries out all the SQL
statements you run and verifies that none of them blows up. Put this in
the continuous build test suite but not in the check-in test suite.

If you're worried about queries being logically wrong, then by all
means, add tests for that. What I recommend people avoid is blindly
running all their data access tests through a live database, because
that's unnecessarily costly. After one gets used to that, one can learn
to break the rules. :)

> On the other hand, tests that access the database (even an in-memory
> database) have a lot of overhead. Have you had any more thoughts on
> the topic since writing your book? (which BTW is a great read).

Thank you for the compliment.

If tests are important, costly to execute but easy to maintain, then put
them in the continuous build test suite so that they at least execute in
the background. If tests are costly to maintain, then question their
value /really hard/ before you decide to keep them; otherwise, replace
them with easier-to-maintain tests. The problem I see is people choosing
to live with costly-to-maintain tests, and it can kill the project.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Predictable, repeatable, quality delivery

I have never seen such framework.

Still, I think you could use a C language based xUnit framework,
compile it as a C ILE service program and call its AssertEquals
procedure from your RPG ILE programs. I must say I haven't tried this
yet.

Just my two cents.

--
Antoine CONTAL

--- In testdrivendevelopment@yahoogroups.com, "hipaa_guru1"
<hipaa_guru1@h...> wrote:
>
> Does anyone know of a unit testing framework for RPG ILE?
>
> I'm afraid this is wishful thinking, but it's worth a shot.
>
> Thanks,
> Keith Reichert

JB,

How do you propose implementation of a "smoke test" of the SQL
statements that:

1. Runs automatically?
2. Does not introduce duplication?

If the SQL statement for my DAO is "select * from dual", how would the
TestCase look? Does this mean that the SQL statement needs to be defined
in a properties file?
________________________________

Chris Richardson wrote:

> However, I am still a little uncomfortable with the idea of not
> automating the tests for the SQL statements. For instance, changes to
> the schema cause SQL statements to not 'compile' and simple mistakes
> such as using a > instead of a >= can cause subtle bugs.

If you're worried about SQL statements not working against schema
changes, then add a smoke test suite that tries out all the SQL
statements you run and verifies that none of them blows up. Put this in
the continuous build test suite but not in the check-in test suite.

If you're worried about queries being logically wrong, then by all
means, add tests for that. What I recommend people avoid is blindly
running all their data access tests through a live database, because
that's unnecessarily costly. After one gets used to that, one can learn
to break the rules. :)

> On the other hand, tests that access the database (even an in-memory
> database) have a lot of overhead. Have you had any more thoughts on
> the topic since writing your book? (which BTW is a great read).

Thank you for the compliment.

If tests are important, costly to execute but easy to maintain, then put

them in the continuous build test suite so that they at least execute in

the background. If tests are costly to maintain, then question their
value /really hard/ before you decide to keep them; otherwise, replace
them with easier-to-maintain tests. The problem I see is people choosing

to live with costly-to-maintain tests, and it can kill the project.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Predictable, repeatable, quality delivery


Yahoo! Groups Sponsor
ADVERTISEMENT
click here
<http://us.ard.yahoo.com/SIG=129v1pikb/M=315388.5497957.6576270.3001176/
D=groups/S=1705007181:HM/EXP=1097710086/A=2372354/R=0/SIG=12id813k2/*htt
ps://www.orchardbank.com/hcs/hcsapplication?pf=PLApply&media=EMYHNL40F21
004SS>

<http://us.adserver.yahoo.com/l?M=315388.5497957.6576270.3001176/D=group
s/S=:HM/A=2372354/rand=138973977>

________________________________

Yahoo! Groups Links


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

* To unsubscribe from this group, send an email to:
	 testdrivendevelopment-unsubscribe@yahoogroups.com
<mailto:testdrivendevelopment-unsubscribe@yahoogroups.com?subject=Unsubs
cribe>

* Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .

Hi folks,

We have a situation where we need to test a state machine that is
effectively a many to many relationship, i.e. "If the User has
privilege X, and the Foo's status is Y, then can the User do Z to
Foo?".

What we're struggling with is how to structure the tests.  We could
use brute force and just write all the setup code for each scenario,
but that leads to a lot of duplication.  We're also looking at
fixtures based on different user privileges, or different statues
of 'Foo'.  The other complication is that for every privilege and
status combination, there are about a dozen methods to call and
verify that their result is what we expect (the actual assertions!).

Any suggestions including the glaringly obvious are welcome.

Dave Rooney
Mayford Technologies
http://www.mayford.ca

Dave Rooney wrote:

> Hi folks,
>
> We have a situation where we need to test a state
> machine that is
> effectively a many to many relationship, i.e. "If
> the User has
> privilege X, and the Foo's status is Y, then can the
> User do Z to
> Foo?".
>
> What we're struggling with is how to structure the
> tests.  We could
> use brute force and just write all the setup code
> for each scenario,
> but that leads to a lot of duplication.  We're also
> looking at
> fixtures based on different user privileges, or
> different statues
> of 'Foo'.  The other complication is that for every
> privilege and
> status combination, there are about a dozen methods
> to call and
> verify that their result is what we expect (the
> actual assertions!).
>
> Any suggestions including the glaringly obvious are
> welcome.

The most obvious thing you didn't mention is Abstract
Tests...

An abstract test suite ABC' targets an abstract base
class ABC.

Concrete classes A, B, and C derive from ABC.

ABC' calls a factory that creates A, B, or C,
typically by overriding setUp().

Three concrete test suites run, A' B' C', all pumping
different concrete object types thru the same test
cases. Further virtual methods override to customize
specific test data, such as some expected results.

In your situation, the spectre of abstract tests with
multiple inheritance raises its ugly head(s). I could
do that, but I don't know how to write about it!

=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

> Any suggestions including the glaringly obvious are welcome.

Here is a glaringly obvious suggestion. Why not make the application
data-driven? e.g. Use an XML table etc. to specify what happens for
a particular combination of privilege and status. Then just test the
mechanism to drive the functionality from the table. In other words,
test each method independently of the privilege and status. Then
test how a privilege and status combination causes a data-specified
method to be executed.

You then have the problem of "testing" the setup of the table
itself, but logically the table is the same data as the actual tests.

Julian

I'm having the nastiest little problem with NUnit, and I can't
figure out how to fix it. We have a team of a dozen users, and not
everyone has this problem.

Here is a sample test class:

using System;
using NUnit.Framework;

namespace Tests.AqPageProcessor
{
	 [TestFixture]
	 public class MyTestFixture
	 {
		 public MyTestFixture()
		 {
		 }

		 [Test]
		 public void Test()
		 {
			 Assert.AreEqual(0,0);
		 }
	 }
}

I reference NUnit.framework.dll in the project. Everything compiles.
When I run the NUnit GUI, it shows me the DLL being loaded, but says
that the assembly has no tests. What am I missing?

Thanks!
Mike