On Sunday 28 April 2002 02:00, Tatsuhiko Miyagawa wrote:
> Here's a patch
> * pass tests in 5.005_03
> * can() should return subref instead of just 1
Thanks, applied! I also added a test to prevent that can() thinko from
reoccurring.
> Seems interesting. But I prefer a direct way to define Mock classes
> manually in a test code like:
>
> package Mock::CGI;
> sub param {
> my($self, $name) = @_;
> return $self->{$name};
> }
>
> package main;
> my $q = bless {}, 'Mock::CGI';
> my $app = WebApp->new($q);
> $app->run;
> It's not so irresistable to me. And doing so gives me a flexibility.
> Well I believe you'll convert me with your future article (on
> perl.com?) ;)
The idea's not very complicated at all. If you know how functions and
methods differ and can localize a code slot in the symbol table, you can do
nearly everything Test::MockObject can do on your own. The same applies to
using only ok() in your tests, or just printing "ok" or "not ok".
As I see it, there are three advantages. These may not always apply:
- it's already done, so if you don't know it's possible or how to do it, you
don't have to figure it out
- for repeated tests, it's a lot shorter and simpler than reproducing code
- it uses Test::Builder, so it integrates nicely with existing tests
There are probably three or four feature types that have yet to be discovered.
If you only need to fake one call, it's not a big advantage. If you need to
test SQL statements sent through DBI, it may come in handy.
I'll show some example code in the article. It will probably end up on
Perl.com (it's for the O'Reilly Network, so it'll be *somewhere*.)
-- c
