Re: C/C++ White-Box Unit Testing and Test::More

[Adrian Howard]

On 26 Jun 2004, at 12:51, Fergal Daly wrote:
On Fri, Jun 25, 2004 at 10:13:52PM +0100, Adrian Howard wrote:
[snip]
What xUnit gives you is a little bit more infrastructure to make these
sorts of task easier.
That's fair enough but that infrastructure is just extra baggage in 
some
cases.
True. The nice thing about Perl's framework is that we can avoid it 
when we don't need it.

Although the extra baggage that people are complaining about is often 
because of the verboseness of a language's OO code rather than xUnit 
itself.

Actually, just after I wrote the email, I realised I had used xUnit 
before, in Delphi. With DUnit, testing a single class takes a 
phenomenal amount of boilerplate code and I guess that's why I'd 
blocked it from my memory :).
I think DUnit would be an example of exactly what I'm talking about. 
For example the following DUnit

unit Project1TestCases;
interface
uses
TestFrameWork;

type
TTestCaseFirst = class(TTestCase)
published
procedure TestFirst;
end;

implementation

procedure TTestCaseFirst.TestFirst;
begin
Check(1 + 1 = 2, 'Catastrophic arithmetic failure!');
end;

initialization
TestFramework.RegisterTest(TTestCaseFirst.Suite);
end.
would be written in Test::Class as:
package Project1TestCases;
use base qw( Test::Class );
use Test::More;

sub catastrophic_arithmetic_failure : Test { is 1+1, 2 };
or, since we don't need any xUnit magic here, as plain old:
use Test::More tests => 1;
is 1+1, 2, 'catastrophic arithmetic failure';
This is why I like Perl!
As you say, we already have a good chunk of xUnit style with 
Test::Harness, with each .t file corresponding somewhat to a "suite" 
but without the nestability.
You could also compare each .t file to a test method, since the tests 
in different .t files tend to be isolated from each other.

I think the baggage only pays for itself when you end up doing a lot of
inheriting between test classes,
For me the baggage pays off as soon as test isolation becomes a factor. 
Having setup/teardown to help create test fixtures saves me typing. 
YMMV.

Adrian

Re: Devel::Cover and nested subroutines

[Geoffrey Young]

> Thanks a lot for the test cases.  I think there are two separate bugs
> here, but I'm only going to take responsibility for one ;-)

:)

> 
> First, mine.  The problem with Foo.pm (the minimal test case) is that
> completely empty subroutines (that is subs which contain no statements
> at all) are ignored as far as subroutine coverage is concerned.  That is
> the case for both named and anonymous subs.  The op tree for an empty
> sub didn't contain the structure I was looking for, so it wasn't
> recognised as a sub.

oh.  cool, I think :)

> 
> I have put in a fix for this, but it only works with Perl 5.8.2 and
> later versions.  I've not gone trying to get it to work with earlier
> versions, since it is pretty obscure and I prefer to keep the code
> reasonably clean.  Or maybe I'm just too lazy.  In any case, let me know
> if this is going to cause anyone problems.  I have documented it as a
> bug though, and upped the recommended version to use from 5.8.1 to 5.8.2.

for minor, obscure issues like this depending on a more recent perl seems
perfectly fine.  especially here, where there isn't any code to create
metrics for anyway.

> 
> Then the second bug.  The problem here is that if you lie to perl it
> will bite your bottom ;-)

that's the quote of the week, for sure :)

>   1.  The coverage will not be reported in the Parser.pm module.

blarg.  but at least there's a reason that makes sense :)

> 
>   2.  Devel::Cover needs to be able to find Parser.yp.  In the example
>   the filename given is Parser.yp, but the file is actually at
>   lib/My/Parser.yp and so Devel::Cover can't find it.  Changing the
>   example to give the full filename, 

you mean changing the #line directive?


>   or putting in a link from the
>   current directory fixes the problem.  I'm not sure if this is
>   actually a problem with Parse::Yapp or just a result of the way
>   you packaged up the testcase.

well, the packaging is pretty much the way the code I'm testing is layed out
- Foo.yp in the same directory as Foo.pm, and all under some lib/ someplace.
 fairly standard I'd think.

but the symlink works - linking Foo.yp to the top-level directory, along
side cover_db.

> 
>   3.  Parse::Yapp doesn't clean up after itself by setting the line
>   number and filename back to what it actually is, which means that
>   subsequent code coverage is reported on in the grammar file even
>   though it didn't come from there, which can be somewhat
>   surprising.

hmph.

> 
> So I'm afraid there's not much I can do about this one - it will need to
> be fed to the author of Parse::Yapp and he can decide if he wants to do
> anything about it.

I suppose I could do that, but it seems kinda strange to ask him to change
stuff around just so we can have good test metrics.  but, per your
suggestion, at least there is a simple workaround - thanks for that.

> In any case, the first fix will be in the next release, 

excellent, thanks.

> and thanks again for the great test cases.

sure thing - thanks for being responsive :)

--Geoff