Re: When test-driven development just won't do

Minor suggestion on the can_ok, based on some code I was recently writing:

no strict 'refs';
ok( defined *{$CLASS."::".$method}{CODE}, "$CLASS has $method")
[download]

At issue for testing is always whether a test really tests what you want. In this case, for example, can_ok $CLASS, $method isn't what you want if you want to know whether a method exists in a particular class. I find that test-driven development works for me because it makes me specify more clearly what behavior I want before I go write the code.

For the first general case you raise, my view is that one writes the test as soon as one knows what the expected behavior is. Until that's defined, playing around is OK. For the second case, while I've not had to tackle that kind of project, if I did, I'd approach it top-down, not bottom up. E.g., write a "total program" test that takes certain input and gives the actual existing output, then start to work on macro testing of major subsystems, etc.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Comment on Re: When test-driven development just won't do Select or Download Code

Replies are listed 'Best First'.
Re^2: When test-driven development just won't do by Ovid (Cardinal) on Aug 04, 2005 at 18:54 UTC
xdg wrote: `no strict 'refs'; ok( defined *{$CLASS."::".$method}{CODE}, "$CLASS has $method")` [download] That fails badly for a number of reasons. If you're just testing a function, it's OK. If you're really testing whether a class provides a given method, it fails. For example, if you have an inherited method, your test fails even though the class "has" the method. Further, the method might no be inherited but also not yet installed in the symbol table, yet `can()` might be overridden to supply the method (I've had to do this for "load on demand" services.) If you have OO code, use Perl's OO facilities to work with it. Just peeking into the namespace isn't enough. Cheers, Ovid New address of my CGI Course.	[reply] [d/l]
Re^3: When test-driven development just won't do by xdg (Monsignor) on Aug 04, 2005 at 19:27 UTC
You're absolutely right -- I wasn't intending to suggest it as a replacement for can_ok. I should have been clear that it's an example for when you want to see if code exists and is not inherited from a superclass (which is what I had needed to check at the time). Doesn't help identify when other modules have exported a function in, or for stuff handled with AUTOLOAD, or installed later, etc. All goes back to my point of needing clarity around what the actual question in before one knows how to write the test. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]


Syntactic Confectionery Delight
	PerlMonks