Hullo Andy,

>
> In these types of scenarios how do we know when to jump from our TDD
> implementation to the utility class or framework?
>

In this scenario I'd most likely have done exactly the same as you have done.

You started with:

* A FileScanner with a full set of tests

* Your in progress class with a developing set of tests.

You noticed a smell, some potential duplication, or observed a similiarity
which could be exploited. I might also have extracted a superclass /
superinterface from the original FileScanner if that made sense given the
context within which I was developing...

When do you know when to jump?

* If you're not confident but have a feeling that this is the right thing to do
then
spike out and satisfy your curiosity.

* If your curiosity proves your feelings were right then go with it.

* If you feel, after spiking, that your original path was more appropriate, then
go with that... It might be time to consider other options that popped into your
mind as you spiked out...


So it sounds like you navigated the possibilities and made sensible step by
step improvements which allowed your current solution to emerge as it is
today. That's TDD in a nutshell. You've got passing tests that codify the intent
of your endeavours which also document the extent to which the solution is
applicable and demonstrate how to use the classes to developers consuming
your code, be they team mates or other customers.


Is mise le meas,


Darach.

On Wednesday, April 30, 2003, at 9:04:30 PM, Scott Stirling wrote:

> These two concerns are highly important on the project I am currently on.
> They are two areas of software design and development that usually receive
> light, if any, treatment in even the best software books.  They're the sort
> of thing you'd like to do well and right, but they are fraught with
> complexity, seeing around corners, and unknowns such as customer
> modifications of our shipped software (which we allow but try to manage by
> externalizing configuration data, limiting customization and extension
> points, etc.).

> They are also the sort of thing one tries not to worry about in test-driven
> development and even agile software methodology in general, aren't they?

Indeed they are. Can you tell us a little more about what kind of situation
you're in, what kind of upgrades, versioning, etc?

Ron Jeffries
www.XProgramming.com
To be on the wire is life. The rest is waiting.  --Karl Wallenda

On Thursday, May 1, 2003, at 2:29:26 AM, Andy Sipe wrote:

> Several times in the last couple of weeks I have come across a similar
> problem.  When doing TDD, how do you know when to jump to a utility or
> framework class to solve your problem?

Hard question. Usually I just go with my intuition of how hard the utility
looks compared to how hard it is to just code what I want. Often I will do
a little spike with the utility, to increase my knowledge and reduce my
fear of it.

Ron Jeffries
www.XProgramming.com
Logic is overrated as a system of thought.

----- Original Message -----
From: "Scott Stirling"
<scottstirling.at.rcn.com@...>
To: "testdrivendevelopment@yahoogroups.com"
<testdrivendevelopment.at.yahoogroups.com@...>
Sent: Wednesday, April 30, 2003 9:04 PM
Subject: [TDD] Upgradability & versioning support


> Hi,
>
> These two concerns are highly important on the project I am currently on.
> They are two areas of software design and development that usually receive
> light, if any, treatment in even the best software books.  They're the
sort
> of thing you'd like to do well and right, but they are fraught with
> complexity, seeing around corners, and unknowns such as customer
> modifications of our shipped software (which we allow but try to manage by
> externalizing configuration data, limiting customization and extension
> points, etc.).

Well, that is a tough one. You've actually got three problems:
upgradability, versioning and customer modifiability.

I suspect the typical XP approach would be to deliver (internally)
several upgrades and versions and let the appropriate architecture
emerge from the experiance of trying to accomplish your goals.

The problem is doing this with software you're delivering to
customers in the face of a customer's ability to modify the
code. In this position, a customer should be able to expect
some amount of release to release stability, and emergent
architecture is the antithesis of this stability, at least while
it is emerging.

If you didn't have customer modifiability, then I'd say just do it
and find out how the architecture wants to emerge. So the
basic question I have is: How important is customer modifiability?

John Roth

>
> Scott Stirling
> Framingham, MA
>

Inaugural Agile Special Interest Group (SIG)
============================================
eXoftware and Best Outcomes, with the support of the Agile Alliance
and the DSDM Consortium have organised the inaugural Agile Special
Interest Group (SIG) to be hosted by IONA. This is a merging of the
XPSIG and the DSDM Regional Interest Group (RIG).

http://www.exoftware.com/news/agile_sig_dublin_1.htm#Registration

When?
Thursday, 15th May at 6:00pm, beer and pizza provided

Where?
IONA facilities in Dublin - Shelbourne Road, Ballsbridge, D4

Why?
To learn more about Agile Methods, and how they can support rapidly
changing business needs.

Topics

"Putting the Agile SIG in context"
Hugh Ivory, Managing Director, Best Outcomes
In this short presentation Hugh will give an overview of the
evolution of the Agile SIG. Hugh will take a look at the advances
in Agile methodologies over the past number of years. This should
ensure that we are all starting from a common understanding.

Hugh Ivory is the Managing Director of Best Outcomes, a
consultancy specialising in Project and Programme Management.
Best Outcomes' core competence is in the use of Agile Methods to
align Process and People, enabling effective Business Change.

Hugh has spent over twenty years in IT within the Financial
Services Industry. He is a Certified DSDM Practitioner, and the
Co-ordinator of the DSDM Irish Regional Interest Group.

"AIB and Agile Methods supporting Business Goals"
Paul Verjans, Snr Manager, Development Support and Quality
Assurance, AIB Bank
Paul will discuss the Change Process Improvement Programme for
which he is responsible at AIB. He will explain the business
drivers for the Programme, and how the required changes have
been prioritised, and implemented on an ongoing basis. He will
describe how AIB has `customised' some Agile methods to suit
its business goals, and its organisation and culture.

"The Story of a Story"
Seán Hanly, Managing Director, eXoftware
When discussing eXtreme Programming it is sometimes difficult
to explain how a requirement is tracked from initial requirements
through to implementation. Using a real user story from a current
eXoftware development project, Sean Hanly will give the "story of
a story" - from initial user story presentation, estimation,
scheduling, delivery of acceptance tests, and implementation
through "Test Driven Development".

Hullo guys,


> Indeed they are. Can you tell us a little more about what kind of situation
> you're in, what kind of upgrades, versioning, etc?
>

The type of upgrade or variance between versions is important metadata to
handle properly (I've yet to find an elegant solution here) but I think the
problem boils down to some fairly simplex fundamentals on the development
side, and some fairly involved choices on the customer-facing side.

Given two versions of a resource or system what characterizes 'good enough'
semantics for a smooth upgrade?

In terms of configuration - provide sensible defaults, keep defaults consistent
between releases? By what do we mean 'consistent'? (ie: maintain
allomorphic integrity).

In terms of APIs and system behaviour (contracts) this is more complicated but
achievable with effort. For example, in the case of APIs if in version 0 I
provide
a user extendable object Foo with method a(String arg), and in version 1 I
provide method Foo with method a unchanged and an additional method b,
where behaviour of a is consistent with version 1 then upgradeability has
been in a sense confirmed...

Both syntactic and semantic consistency of contracts impact upgradeability.

Of course, If I changed the signature of method a, or remove object Foo then
upgradeability has been in some sense compromised. Just like if the
behaviour of foo changes in a significant and inconsistent way this is a
compromise to upgradeability. Through complicating, changing or restricting
a customers expectation of modifiability/flexibility we have again
compromised on upgradability.

In terms of a patch or point release this may be unacceptable for 'public' APIs
or configuration. In terms of a full release binary compatibility is more
reasonably compromised as long as a reasonable attempt to provide a
migration path to your customer is provided.

Would classifying upgradeability at the unit level, package level, system level
and domain level and the ability to validate against such an upgradeability
specification resolve the problem with sufficient confidence?

I think it would, and having a specification which may be validated against the
resources, public APIs and extension points, sensible defaults to
configurations, features etc.. in a fully automatable way would be consistent
with the intent of TDD as:

* During releases where upgradeability must not be compromised the
specification may be 'tested' against the current product image and behaviour.

* During releases where planned upgrades are existant (ie: the specification
changes) then this too is assertable.

I dont know of any commercial or open source tools which support such a
notion. Does anyone else on this list know of one?

The crux of a solution would be a meaning encapsulation of the wide and
sundry metadata required in the construction of a formal specification and tool
support in validating it against the new and old product 'images'.

Conceivably an 'advanced' solution would also support some kind of hot re-
deployment of upgrade consistent 'modules' to a deployed/production system.

This problem though I think is probably more easily defineable than it is
solveable without significant investment and effort. And the definition is, too,
by no means easy to define!!!

For example, if all your system tests and component tests for all scenarios
pass on version 2 of some product, and all planned impact on the customer is
clearly communicated and catered for with upgrade solutions (migration tools,
documentation, services...).

In terms of any public APIs then binary compatibility is another point about
which upgradability needs to be planned...


It would certainly be a most welcome and most agile tool during any release
of any size if the metadata here could be well defined and utilized to
automatically assert conformance where needed and allow exceptions where
agreed with the customer.


At a guess, if syntactic and semantic variation is suitably recordable then that
subset which asserts good upgradeability could be played back against a
product image. For example, is this something which would make sense in
terms of Executable UML where you have a common semantic model for both
the syntactic (visual in this case) and semantic (OCL and Action Semantics)
points about which this ultimately revolves? I think so, but it might take quite
the mythical manmonth to develop a solution for it!


Is mise le meas,


Darach.

----- Original Message -----
From: "darach_ennis" <darach.ennis.at.iona.com@...>
To: "testdrivendevelopment@yahoogroups.com"
<testdrivendevelopment.at.yahoogroups.com@...>
Sent: Thursday, May 01, 2003 1:34 PM
Subject: [TDD] Re: Upgradability & versioning support


> Hullo guys,
>
>
> > Indeed they are. Can you tell us a little more about what kind of
situation
> > you're in, what kind of upgrades, versioning, etc?
> >
>
> The type of upgrade or variance between versions is important metadata to
> handle properly (I've yet to find an elegant solution here) but I think
the
> problem boils down to some fairly simplex fundamentals on the development
> side, and some fairly involved choices on the customer-facing side.
>
> Given two versions of a resource or system what characterizes 'good
enough'
> semantics for a smooth upgrade?
>
> In terms of configuration - provide sensible defaults, keep defaults
consistent
> between releases? By what do we mean 'consistent'? (ie: maintain
> allomorphic integrity).
>
> In terms of APIs and system behaviour (contracts) this is more complicated
but
> achievable with effort. For example, in the case of APIs if in version 0 I
provide
> a user extendable object Foo with method a(String arg), and in version 1 I
> provide method Foo with method a unchanged and an additional method b,
> where behaviour of a is consistent with version 1 then upgradeability has
> been in a sense confirmed...
>
> Both syntactic and semantic consistency of contracts impact
upgradeability.
>
> Of course, If I changed the signature of method a, or remove object Foo
then
> upgradeability has been in some sense compromised. Just like if the
> behaviour of foo changes in a significant and inconsistent way this is a
> compromise to upgradeability. Through complicating, changing or
restricting
> a customers expectation of modifiability/flexibility we have again
> compromised on upgradability.
>
> In terms of a patch or point release this may be unacceptable for 'public'
APIs
> or configuration. In terms of a full release binary compatibility is more
> reasonably compromised as long as a reasonable attempt to provide a
> migration path to your customer is provided.
>
> Would classifying upgradeability at the unit level, package level, system
level
> and domain level and the ability to validate against such an
upgradeability
> specification resolve the problem with sufficient confidence?
>
> I think it would, and having a specification which may be validated
against the
> resources, public APIs and extension points, sensible defaults to
> configurations, features etc.. in a fully automatable way would be
consistent
> with the intent of TDD as:
>
> * During releases where upgradeability must not be compromised the
> specification may be 'tested' against the current product image and
behaviour.
>
> * During releases where planned upgrades are existant (ie: the
specification
> changes) then this too is assertable.
>
> I dont know of any commercial or open source tools which support such a
> notion. Does anyone else on this list know of one?
>
> The crux of a solution would be a meaning encapsulation of the wide and
> sundry metadata required in the construction of a formal specification and
tool
> support in validating it against the new and old product 'images'.
>
> Conceivably an 'advanced' solution would also support some kind of hot re-
> deployment of upgrade consistent 'modules' to a deployed/production
system.
>
> This problem though I think is probably more easily defineable than it is
> solveable without significant investment and effort. And the definition
is, too,
> by no means easy to define!!!
>
> For example, if all your system tests and component tests for all
scenarios
> pass on version 2 of some product, and all planned impact on the customer
is
> clearly communicated and catered for with upgrade solutions (migration
tools,
> documentation, services...).
>
> In terms of any public APIs then binary compatibility is another point
about
> which upgradability needs to be planned...
>
>
> It would certainly be a most welcome and most agile tool during any
release
> of any size if the metadata here could be well defined and utilized to
> automatically assert conformance where needed and allow exceptions where
> agreed with the customer.
>
>
> At a guess, if syntactic and semantic variation is suitably recordable
then that
> subset which asserts good upgradeability could be played back against a
> product image. For example, is this something which would make sense in
> terms of Executable UML where you have a common semantic model for both
> the syntactic (visual in this case) and semantic (OCL and Action
Semantics)
> points about which this ultimately revolves? I think so, but it might take
quite
> the mythical manmonth to develop a solution for it!

I originally thought you were talking about something more complex
than the standard upgrade problem that everyone faces at one time or
another.

The solution here is a comprehensive set of customer and programmer
tests. If the new version can pass all of the customer and programmer
tests for the old version, then the upgrade should be transparent.

John Roth
>
>
> Is mise le meas,
>
>
> Darach.
>
>
>
> To unsubscribe from this group, send an email to:
> testdrivendevelopment-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

OK, I've been converted to TDD over the last couple of weeks after
reading a lot of the online material.  Thank you to everyone who has
posted information on the web it makes it much easier to research and
I'm totally converted.

I have been working on a project for over a year now and I'd like to
start applying TDD principles.  The way I see it I will use TDD for
all new additions to the code and when I'm not working on a spec I'll
add test cases for existing code.  Better late than never right?

However, I have a piece in my code where I dynamically fill an array
based on the current date and I'm curious as to how to test /
refactor the code.  The location of the current day in the month has
proven to cause some bugs in my code so I want to make sure I have
some good unit test coverage here.  For instance, yesterday being the
1st of May gave me some trouble.  The code creates the array based on
the date so (using C#) I start out with
          DateTime today = DateTime.Now;
I then create an array of dates using the 'today' variable as the
base.  I would like to be able to change the date for today from my
tests so that I know it will work on the 1st, 15th, 30th, etc.
However 'today' is a temporary variable used in a function that gets
called only once by the object for the runtime of the process.  (The
array is static and only gets created if it is null which is at the
start of the process)

I'm looking for some advice from those of you who have done Unit
testing for a while as I have no experience here.  Do I make 'today'
a member variable of the class so that I can set up the variable for
test purposes even though it has nothing to do with the class?  That
doesn't seem to 'feel' right with OO principles I've learned in the
past.  Is there another way to do what I'm trying to do?  I would
like my code to remain focused on the solution and the test code to
be an add-on not integrated.  Maybe I'm wrong in that thought and
need to integrate the tests.

Thanks for any help,
Corey

From: "cmaxo2000" <cmaxo2000@...>
>The code creates the array based on
>the date so (using C#) I start out with
>          DateTime today = DateTime.Now;
>I would like to be able to change the date
>for today from my tests so that I know it
>will work on the 1st, 15th, 30th, etc.
>However 'today' is a temporary variable
>used in a function that gets called only once
>by the object for the runtime of the process.

This is a great place to use a simple refactoring.
As you've guessed, we're going to suggest that you
extract the local variable to the class level, and
set it there -- but because you only use it once,
I suggest that you first extract the method that's
setting and using the local variable into a class of
its own.

So, to create your array you'll test if it's null;
if it is, you'll create an ArrayCreator object,
passing in the current date. You'll then call
that class with the array, which it'll fill, and
then you can destroy the ArrayCreator object.

This way, you can test the ArrayCreator object
with any date you want.

> Corey

-Billy

This might be a good topic for Mike F.'s Legacy Monkeywrench mailing list,
so I CC'd it into there. (Under the wild assumption Mike might just be
pro-TDD.)

----- Original Message -----
From: "cmaxo2000" <cmaxo2000@...>
To: <testdrivendevelopment@yahoogroups.com>
Sent: Friday, 02 May, 2003 2:05 PM
Subject: [TDD] Adding TDD after the fact


> OK, I've been converted to TDD over the last couple of weeks after
> reading a lot of the online material.  Thank you to everyone who has
> posted information on the web it makes it much easier to research and
> I'm totally converted.
>
> I have been working on a project for over a year now and I'd like to
> start applying TDD principles.  The way I see it I will use TDD for
> all new additions to the code and when I'm not working on a spec I'll
> add test cases for existing code.  Better late than never right?
>
> However, I have a piece in my code where I dynamically fill an array
> based on the current date and I'm curious as to how to test /
> refactor the code.  The location of the current day in the month has
> proven to cause some bugs in my code so I want to make sure I have
> some good unit test coverage here.  For instance, yesterday being the
> 1st of May gave me some trouble.  The code creates the array based on
> the date so (using C#) I start out with
>          DateTime today = DateTime.Now;
> I then create an array of dates using the 'today' variable as the
> base.  I would like to be able to change the date for today from my
> tests so that I know it will work on the 1st, 15th, 30th, etc.
> However 'today' is a temporary variable used in a function that gets
> called only once by the object for the runtime of the process.  (The
> array is static and only gets created if it is null which is at the
> start of the process)
>
> I'm looking for some advice from those of you who have done Unit
> testing for a while as I have no experience here.  Do I make 'today'
> a member variable of the class so that I can set up the variable for
> test purposes even though it has nothing to do with the class?  That
> doesn't seem to 'feel' right with OO principles I've learned in the
> past.  Is there another way to do what I'm trying to do?  I would
> like my code to remain focused on the solution and the test code to
> be an add-on not integrated.  Maybe I'm wrong in that thought and
> need to integrate the tests.
>
> Thanks for any help,
> Corey
>
>
>
> To unsubscribe from this group, send an email to:
> testdrivendevelopment-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

How about this:

Change your call from DateTime today = DateTime.Now

to:

DateTime today = GetCurrentDateTime()

(or better yet since it is C# - change it to a property :

virtual DateTime Today
{
	 get{return DateTime.Now;}
}

Now for testing - subclass this class and override the property DateTime to
return a date that you have initialized the test class with.  In a little more
detail:

public class OriginalClass
{

virtual DateTime Today{
	 get{return DateTime.Now;}
}
}

public class TestableClass : OriginalClass{

public TestableClass(DateTime today)
{
_today = today;
}

override DateTime Today{
	 get{ return _today;}
}
}


and then u can use NUnit to test OriginalClass.


Amr Elssamadisy

>  -----Original Message-----
> From:  cmaxo2000@... [mailto:cmaxo2000@...] > Sent: Friday, May
02, 2003 4:06 PM
> To: testdrivendevelopment@yahoogroups.com; >
testdrivendevelopment@yahoogroups.com
> Subject: [TDD] Adding TDD after the fact
> > OK, I've been converted to TDD over the last couple of weeks > after reading
a lot of the online material.  Thank you to > everyone who has posted
information on the web it makes it > much easier to research and I'm totally
converted.
> > I have been working on a project for over a year now and I'd > like to start
applying TDD principles.  The way I see it I > will use TDD for all new
additions to the code and when I'm > not working on a spec I'll add test cases
for existing code.  > Better late than never right?
> > However, I have a piece in my code where I dynamically fill > an array based
on the current date and I'm curious as to how > to test / refactor the code. 
The location of the current day > in the month has proven to cause some bugs in
my code so I > want to make sure I have some good unit test coverage here.  >
For instance, yesterday being the 1st of May gave me some > trouble.  The code
creates the array based on the date so > (using C#) I start out with         
DateTime today = DateTime.Now;
> I then create an array of dates using the 'today' variable as > the base.  I
would like to be able to change the date for > today from my tests so that I
know it will work on the 1st, > 15th, 30th, etc.  However 'today' is a temporary
variable > used in a function that gets called only once by the object > for the
runtime of the process.  (The array is static and > only gets created if it is
null which is at the start of the process)
> > I'm looking for some advice from those of you who have done > Unit testing
for a while as I have no experience here.  Do I > make 'today' a member variable
of the class so that I can set > up the variable for test purposes even though
it has nothing > to do with the class?  That doesn't seem to 'feel' right with >
OO principles I've learned in the past.  Is there another way > to do what I'm
trying to do?  I would like my code to remain > focused on the solution and the
test code to be an add-on not > integrated.  Maybe I'm wrong in that thought and
need to > integrate the tests.
> > Thanks for any help,
> Corey
> > > ------------------------ Yahoo! Groups Sponsor > ---------------------~-->
> Rent DVDs from home.
> Over 14,500 titles. Free Shipping
> & No Late Fees. Try Netflix for FREE!
> http://us.click.yahoo.com/BVVfoB/hP.FAA/uetFAA/NhFolB/TM
> --------------------------------------------------------------
> -------~->
> > To unsubscribe from this group, send an email to:
> testdrivendevelopment-unsubscribe@yahoogroups.com
> >  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
<< File: ENVELOPE.TXT >>

Agghh!  I can see that I will begin to start using objects a lot more
as I learn to refactor.  This is an excellent suggestion.

Thanks everyone for the suggestions,
Corey

--- In testdrivendevelopment@yahoogroups.com, <wtanksleyjr@c...>
wrote:
> From: "cmaxo2000" <cmaxo2000@y...>
> >The code creates the array based on
> >the date so (using C#) I start out with
> >          DateTime today = DateTime.Now;
> >I would like to be able to change the date
> >for today from my tests so that I know it
> >will work on the 1st, 15th, 30th, etc.
> >However 'today' is a temporary variable
> >used in a function that gets called only once
> >by the object for the runtime of the process.
>
> This is a great place to use a simple refactoring.
> As you've guessed, we're going to suggest that you
> extract the local variable to the class level, and
> set it there -- but because you only use it once,
> I suggest that you first extract the method that's
> setting and using the local variable into a class of
> its own.
>
> So, to create your array you'll test if it's null;
> if it is, you'll create an ArrayCreator object,
> passing in the current date. You'll then call
> that class with the array, which it'll fill, and
> then you can destroy the ArrayCreator object.
>
> This way, you can test the ArrayCreator object
> with any date you want.
>
> > Corey
>
> -Billy

I handle testing different times somewhat differently. I change the
global notion of time rather than passing times into objects or
methods. That's somewhat untraditional, but I argue Time is a special
case.
<http://www.testing.com/cgi-bin/blog/2003/05/03#Time.rb>

I don't know if it would work in C#.


-----
Brian Marick
Consulting, training, contracting, and research
Focused on the intersection of testing, programming, and design
marick@..., marick@...
www.testing.com, www.visibleworkings.com

I'm program chair or cohost of these events:
PLoP: <http://jerry.cs.uiuc.edu/~plop/plop2003/>
Analogy Fest: <http://www.visibleworkings.com/analogyfest/>
Please join me.

Saturday, May 03, 2003, 12:47:56 PM, Brian Marick wrote:

> I handle testing different times somewhat differently. I change the
> global notion of time rather than passing times into objects or
> methods. That's somewhat untraditional, but I argue Time is a special
> case.
> <http://www.testing.com/cgi-bin/blog/2003/05/03#Time.rb>

> I don't know if it would work in C#.

This pattern works, and we use it also, in Smalltalk.


--

  Doug Swartz
  daswartz@...

Thanks for the suggestion.  I like the idea of being able to change
the notion of time for the system.  I could really do a lot more with
my tests if I could test all different scenarios by affecting the
value of the now.

--- In testdrivendevelopment@yahoogroups.com, Doug Swartz
<daswartz@p...> wrote:
>
> Saturday, May 03, 2003, 12:47:56 PM, Brian Marick wrote:
>
> > I handle testing different times somewhat differently. I change
the
> > global notion of time rather than passing times into objects or
> > methods. That's somewhat untraditional, but I argue Time is a
special
> > case.
> > <http://www.testing.com/cgi-bin/blog/2003/05/03#Time.rb>
>
> > I don't know if it would work in C#.
>
> This pattern works, and we use it also, in Smalltalk.
>
>
> --
>
>  Doug Swartz
>  daswartz@p...

On Sat, 3 May 2003, cmaxo2000 wrote:

> Agghh!  I can see that I will begin to start using objects a lot more
> as I learn to refactor.  This is an excellent suggestion.

Yes you will <evil grin>.  If you haven't read the Refactoring book yet,
do so immediately.  I found after reading it that what I thought was
object oriented programming simply wasn't.  Refactoring really helps you
see the intention of your code.

JobFinder Software
------------------

This is what JobFinder does

- Search the newspapers for ads following you criteria
- You can chose the cities that you like to target for employment
- Automatic, install and receive the employment offers
- It sends attachments, links, etc.
- You don't even need to buy the paper, my program downloads it from the net.

If you are interested in downloading a copy,
http://jaimemedina.net/JobFinder/
<a href="http://jaimemedina.net/JobFinder/">AOL users click here</a>

Now the employment offers:
-------------------------

COMPUTER CLERK
--------------
My company needs clerk for computer job. You will do it over the net from home.
We will pay you US $12 per hour. You must pass a test. You will not be paid  for
the test. You will take the test at home, you need Internet access. Available to
anyone in the world.
You chose the hours and days that you work.
If interested, go to:
http://jaimemedina.net/JobFinder/Clerk/
<a href="http://jaimemedina.net/JobFinder/Clerk/">AOL users click here</a>

SALESPERSON
-----------
Business to business, face to face. US $60,000 to $100,000+ a year, commission
only. Full training. Available in the USA only. Send me your resume if
interested. Management opportunities for the best reps.
You chose the hours and days that you work.

Best Regards,

Jaime Medina

[from: RE: [TDD] Digest Number 405]

> > Agghh!  I can see that I will begin to start using objects
> a lot more
> > as I learn to refactor.  This is an excellent suggestion.
>
> Yes you will <evil grin>.  If you haven't read the
> Refactoring book yet,
--snip--

"Refactoring book"?  What book is this?  I looked in the TDD Yahoo group
pages and found no mention of such a book (or any books for that matter -
perhaps I didn't look in the right place)


Regards,
Warwick.


********************************************************************************\
***
The information in this e-mail message and any files transmitted with it
are intended to be confidential and for the use of only the individual or
entity to whom they are addressed. The message and files may be
protected by legal professional privilege, or other legal rules. The
confidentiality of and privilege applying to this message and
files is not waived if this message or files has been sent to you by mistake.
If the reader of this message or files is not the intended recipient, you are
notified that retention, distribution or copying of this message and files are
strictly prohibited.  If you receive this message or files in error, please
notify us immediately by telephone or return e-mail and delete all copies
from your computer system. It is the recipient's responsibility to check this
message and files for viruses.

Thank you.
********************************************************************************\
***

Molloy, Warwick sez:

> "Refactoring book"?  What book is this?  I looked in the TDD Yahoo group
> pages and found no mention of such a book (or any books for that matter -
> perhaps I didn't look in the right place)

The first two XP books, in order, were

   Refactoring, improving the design of existing code, by Martin Fowler
   Extreme Programming Explained by Bent Keck.

Hence, The Refactoring Book. And The White Book.

--
   Phlip
     http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

On Monday, May 5, 2003, at 9:30:30 PM, Molloy, Warwick wrote:

> "Refactoring book"?  What book is this?  I looked in the TDD Yahoo group
> pages and found no mention of such a book (or any books for that matter -
> perhaps I didn't look in the right place)

Try a book store, online or otherwise. Look for a book named "Refactoring"
by Martin Fowler.

Ron Jeffries
www.XProgramming.com
If names and real items do not correspond with each other, there will be
fighting.
   -- Jing Fa

The next Phoenix eXtreme Programming User Group meeting will be held on Monday, May 12th. This is an informal gathering of Phoenix area developers and project managers who are interested in agile software development, especially, eXtreme Programming (XP). If you want to find out more about agile software development, this is the place to go!

We have a new Yahoo! Group! Subscribe to http://groups.yahoo.com/group/XpPhoenix of upcoming agile development events in Phoenix, AZ.

If you plan to attend, please RSVP mailto:jay.turpin@... so I can make sure we have a large enough room.
Topic: eXtreme Programming Overview - This is an excellent presentation for managers and developers alike. This is a general overview of eXtreme Programming during which we will discuss XP practices and describe how they work together to improve the software development process.
Presenter: Jay Turpin, Intel
Date: Monday, May 12th, 2003
Time: 7:00-9:00 PM
Where: Intel Corporation
5000 W Chandler Blvd.
Chandler, AZ 85226
Building: C7
Room: C7110 - in C7 Lobby
Directions: Drive east on Chandler Blvd from I-10. Turn left (north) at Rural Road. Drive 1/2 mile to Galveston. Turn left. Drive about a 1/4 mile and look for the first driveway on the left and turn into the Intel campus. Building C7 is immediately in front of you. Come in the C7 lobby and follow the signs.

http://maps.yahoo.com/py/maps.py?BFCat=&Pyt=Tmap&addr=5500+W+Chandler+Blvd&city=Chandler&state=AZ&slt=33.305700&sln=-111.928700&name=Work&zip=85226-3601&country=us&mag=9&cs=9&BFClient=&BFKey=&poi=&poititle=&map.x=86&map.y=193

Hullo John, all,

> I originally thought you were talking about something more complex
> than the standard upgrade problem that everyone faces at one time or
> another.
>

> The solution here is a comprehensive set of customer and programmer
> tests. If the new version can pass all of the customer and programmer
> tests for the old version, then the upgrade should be transparent.
>

Excellent answer :)

The standard upgrade problem is complex. The question I'm asking myself
and I guess the group is if there is a way to reduce the precentage of
comprehensive tests which require to be written/maintained manually as
opposed to via code generation...

I believe many of the tests I have written manually and that I currently
maintain
having adopted TDD are avoidable and could have benefited from being
generated as opposed to written... This I believe to be especially true of
upgrade/version/binary-compatibility style tests where concistency across
versions is a requirement.

There is a process implicit here:

* Provide comprehensive tests in the usual way (eg: via TDD specifically)
* Recognize that subset which are largely formulaic (some pattern emerges)
* Leverage through codifying the formula as a code generator which
generates your tests based on available metadata.

An example: File and directory naming and structure in a set of related
products should be consistent... This could benefit from a custom validation
tool reusable across multiple products verses a plethora of tests...

Perhaps I'm mixing 'agile' with 'TDD' here just a little bit...


Is mise le meas,


Darach.

Test Infection Vectors:

My project has an XML generator that returns strings full of serialized
data; they are typically short.

I want to spool a sample of the XML, copy it into the test, and then compare
it to new output from the same generator, but at the data level, not the
byte level.

Library of choice is either expat or MSXML.

I'd start writing, but I have to think someone has solved this and tossed
the code somewhere on the 'net.

--
   Phlip
     http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

Phlip wrote:

>Test Infection Vectors:
>
>My project has an XML generator that returns strings full of serialized
>data; they are typically short.
>
>I want to spool a sample of the XML, copy it into the test, and then compare
>it to new output from the same generator, but at the data level, not the
>byte level.
>
>Library of choice is either expat or MSXML.
>
>I'd start writing, but I have to think someone has solved this and tossed
>the code somewhere on the 'net.
>
>

Perhaps I'm missing something, but maybe it's XmlUnit you're looking for:

     http://xmlunit.sourceforge.net/

Or maybe it's just a starting point.

Mike

> Perhaps I'm missing something, but maybe it's XmlUnit you're looking for:
>
>     http://xmlunit.sourceforge.net/

<before I even click the link>

D'OH!

My wife now hates you for giving me a weekend project...

--
   Phlip
     http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

> > Perhaps I'm missing something, but maybe it's XmlUnit you're looking
for:
> >
> >     http://xmlunit.sourceforge.net/

Uh, need C++ or Perl.

--
   Phlip
     http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

My wife now hates you for giving me a weekend project...

Uh, need C++ or Perl.

-- Mike Clark
http://clarkware.com
(303) 589-3812

CC'd to TFUI because XPath's a great way to proof HTML.

> Now she really hates me.  Is that port done yet?  :-)

Went with libxml and XPath instead.

Spot-checking the XML is more flexible than a soft string match, because you
could never have gotten soft enough to avoid false negatives over missing
records that don't matter, and such.

So, here's a C++ wrapper on libxml's XPath that does the trick:

     class
ExPath
{
   public:
     ExPath(char const * contents):
         m_context(NULL),
         m_document(xmlParseDoc(BAD_CAST contents))
             {
             ATLASSERT(m_document);
             m_context = xmlXPathNewContext(m_document);
             ATLASSERT(m_context);
             }

     ExPath(xmlDocPtr document):
         m_context(xmlXPathNewContext(document)),
         m_document(NULL)
             {
             ATLASSERT(m_context);
             }

    ~ExPath()
         {
         xmlXPathFreeContext(m_context);
      xmlFreeDoc(document);  //  these can survive nulls
         }

         string
     operator()(char const *path, bool reveal = false)
         {
         xmlXPathObjectPtr res = xmlXPathEvalExpression(BAD_CAST path,
m_context);
         ATLASSERT(res);  //  this happens when path is bogus
         //  TODO  is this string leaking?
         xmlChar * contents = xmlXPathCastToString(res);
         ATLASSERT(contents);

         if (reveal)  //  replace with cout or something here
             db(quoteMeta_<char>(contents));

         xmlXPathFreeObject(res);
         return (char *)contents;
         }

   private:
     xmlXPathContextPtr m_context;
     xmlDocPtr          m_document;
};

...

    ExPath aPath (bunchaXml);
    CPPUNIT_ASSERT_EQUAL("party time", aPath("/any/time"));

If I knew enough about xmlXPathCastToString() and the other things you can
do with an xmlXPathObjectPtr, we could return more clever things from
ExPath.

About the wifey situation - yes I'l drive you all the way to your favorite
mall, honey. Even if I wear the batteries out of my notebook while you shop
your brains out, I know where there's a power outlet in the back of
Nordstrom's Cafe.

Another engineering problem solved!

--
   Phlip
     http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

there is a tool in gotdotnet to compare two xml docs, please take a
look at:

http://apps.gotdotnet.com/xmltools/xmldiff/

"Phlip" <plumlee@s...>
Spot-checking the XML is more flexible than a soft string match,
because you could never have gotten soft enough to avoid false
negatives over missing records that don't matter, and such.


Well, do what works, of course, but this attitude surprises me a
bit.  I'd normally want an exact comparison (if a refactoring changes
the behavior of the app, I want to know immediately.  If I decide
that's acceptable, I'll change the test to match).

I expect XSLT to bail me out if a large number of gold files need to
be changed.

However, this sort of thing might make more sense for regression
tests than programmer tests.

Danil