<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I can't argue adding tests per change is a good idea.<BR>
I was on a team where at least every bug fix had to come with an automatic regression test, if not every initial change, though of course, you could do the second. My problem historically has been lack of a framework -- how to write tests, how to run them, how to verify them, how to debug them. m3-sys\m3tests appears to be a plenty adequate framework for locally authoring, running, verifying, debugging, plus the tinderbox for ongoing status (not that, as far as I know, the tinderbox is debuggable in-situ, but still, this is plenty).<BR>
<BR>I submitted the change but disabled. It's now a very small diff to enable<BR>
<BR>
What is the story on exposing internals to testing though?<BR>
<BR>I see several options, all with pluses and minus:<BR>
<BR>
Expose more stuff in the .i3 file.<BR>
Possibly with names like "Internal" or "Test" in them.<BR>
Not great but easy and works.<BR>
<BR>
Invoke test code from module initialization having checked Params for M3testfoo or such.<BR>
Not great but easy and often works.<BR>
Adds unnecessary code to the runtime.<BR>
<BR>
Getting better I think:<BR>
Add FooInternal.i3 or FooTest.i3.<BR>
Export it from Foo.m3. I guess even to the pkg store?<BR>
Call it from the text executable (also want to call FooTest.m3).<BR>
This still exposes internals to callers, but at least with a clear distinction of what is internal or not.<BR>
I guess another name here is FooFriend.i3.<BR>
<BR>
For that matter, split off the testable code into FooTest.m3. Same thing?<BR>
<BR>Somehow "preprocess" the code to extract parts you want to call from test code.<BR>
I'm not keen on designing a preprocessor.<BR>
<BR>
Aha, combine the last few?<BR>
Split up Foo.m3 into FooTest.m3 and Foo.m3. Both exports only parts of Foo.i3, which is unchanged.<BR>
Add FooTest.i3 that is empty?<BR>
"Preprocessing" becomes a) copy an .m3 file b) replace an .i3 file (FooTest.i3)? There, I designed preprocessing, as file copying.<BR>
<BR>
There's also the matter of chosing the test cases that matter and not just a bunch of random strings that are obviously handled correctly but I guess just err toward throwing in more strings.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Tue, 26 Feb 2008 11:36:07 +0100<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: [M3devel] Extending the tests, was: Re: M3Path.FixPath rewrite?<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> <BR>> > M3Path.FixPath had some flaws, mainly: it uses a fixed size array <BR>> > to store the locations of path separators in the presence of too <BR>> > many separators, it'd ignore stuff every occurence of . or .. <BR>> > causes it to restart its work (after removing it)<BR>> > I have written a new version with these aspects fixed.<BR>> > Anyone care to try it out?<BR>> > diff and m3path.m3 attached.<BR>> > There's a small test harness built in, disabled.<BR>> > You can feed strings through the old and new and compare.<BR>> > They don't always match. I think my results are "more correct".<BR>> <BR>> Sorry, it will take some time till I can test these.<BR>> <BR>> Why don't you add the test to the package test framework<BR>> in m3-sys/cm3/tests/src/TestM3Path or similar?<BR>> Provide a list of input paths and expected output in files;<BR>> this will make things easier to understand for others.<BR>> If you add the tests first and wait one day until checking in<BR>> your change we can see the impacts in the package test results<BR>> in our tinderbox.<BR>> <BR>> Generally I think we should start adding tests for everything we<BR>> change; there's so much breakage that can be avoided this way.<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR><br /><hr />Helping your favorite cause is as easy as instant messaging. You IM, we give. <a href='http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join' target='_new'>Learn more.</a></body>
</html>