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
