Mike.Olson at fourthought.com
Fri Jul 27 15:12:43 MDT 2001
> Well, maybe... If the rest of the system was expecting the "broken"
> behavior, then that code will probably break. Hopefully, the tests were
> incomplete or broken, and the rest of the system was actually relying on
> the correct behavior so the rest of the system should now operate
See, to me that oversimplifies it. I guess my recent experiences with
finite input finite output have shown me that side effects (even though
considered correct) can break the system.
> Also, I like to see the tests available to exercise things on new
> platforms, to verify the code when porting. So I don't think they're
> useless once you have the code working...
If you are doing the porting, then I'll argue you are doing new
development and then these would be usefully.
If you are given a port, and you get a message of "Function XYZ failed"
that does not help you at all. Getting a message from a higher level
test will probably be more usefull.
Please don't read into this that there are no test scripts. Just higher
level test scripts.
Also, the XP folks would say
> that if you're re-engineering the code, the unit-tests can ensure that you
> can plug a new chunk of code in place of another one in a system and
> hopefully have the original functionality of the whole system...
But for what reason are you re-engineering the code? I have seen very
few (in fact I cannot think of any) cases where you take one piece of
code, drastically re-engineer it, change none of the
interfaces/contracts with the outside world, and plug it back in where
You need to re-engineer it for a reason, performance, resource
utilization, etc. and to accomplish these tasks, 95% of the time you
will need to change an interface to do it. You need more of something
available to you.
Unless of course you are early in the lifecycle of a project, in which
case, yes I use unit tests alot.
> Find out just what any people will quietly submit to and you have the exact
> measure of the injustice and wrong which will be imposed on them. -- T.J.
> Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
> This message sent by the FRPythoneers mailing list.
> Unsubscribe: echo unsubscribe | FRPythoneers-request at lists.community.tummy.com
> URL: http://lists.community.tummy.com/mailman/listinfo/frpythoneers
Mike Olson Principal Consultant
mike.olson at fourthought.com +1 303 583 9900 x 102
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, http://4Suite.org
Boulder, CO 80301-2537, USA
XML strategy, XML tools, knowledge management
More information about the FRPythoneers