Re: Anyone want Test::Class::Moose?

It's seriously alpha and has a nasty bug whereby an exception will halt the entire test suite.

I can fix that later, but I wanted to get something out for you folks.

https://github.com/Ovid/test-class-moose

 
Note that I elected to not use attributes because they're hard for *you* to customize, but it's trivial for you to override the get_test_classes() and get_test_methods() behavior for your own testing purposes.

More work needs to be done, but I think you'll be pleased at how short the code is to do this.

Cheers,
Ovid
--
Twitter - http://twitter.com/OvidPerl/
Buy my book - http://bit.ly/beginning_perl
Buy my other book - http://www.oreilly.com/catalog/perlhks/
Live and work overseas - http://www.overseas-exile.com/


>________________________________
> From: Jonathan Swartz <[email protected]>
>To: Ovid <[email protected]> 
>Cc: Perl QA <[email protected]> 
>Sent: Wednesday, 12 December 2012, 19:18
>Subject: Re: Anyone want Test::Class::Moose?
> 
>+1 from me! I like Test::Class and would welcome a Moose-ish variety.
>
>On Dec 12, 2012, at 9:51 AM, Ovid <[email protected]> wrote:
>
>> Hi all,
>> 
>> People keep asking me how to properly integrate Moose with Test::Class. I know about Test::Able and some alternatives, but I *generally* like Test::Class's interface (or maybe I'm just in a comfort zone). So I wrote my own Test::Class::Moose (it does not use Test::Class) and it uses subtests all the way down.
>> 
>> Every test class is one test. Every test method is a subtest in the test class. Every test in a test method is, well, one test in a test method. Here's a simple test class which, in turn, inherits from another test class (you get all of the functions from Test::Most along with Moose helper functions, if desired):
>> 
>>     package TestsFor::Basic::Subclass;                                                                                                                  
>>     use Test::Class::Moose parent => 'TestsFor::Basic';
>> 
>>     sub test_startup {
>>         my $test = shift;
>>         $test->next::method;
>>         # more startup here, but tests are not allowed
>>     }
>> 
>>     sub test_me {
>>         my $test  = shift;
>>         my $class = $test->this_class;
>>         ok 1, "I overrode my parent! ($class)";
>>     }
>> 
>>     before 'test_this_baby' => sub {
>>         my $test  = shift;
>>         my $class = $test->this_class;
>>         pass "This should run before my parent method ($class)";
>>     };
>> 
>>     sub this_should_not_run {
>>         fail "We should never see this test";
>>     }
>> 
>>     sub test_this_should_be_run {
>>         for ( 1 .. 5 ) {
>>             pass "This is test number $_ in this method";
>>         }
>>     }
>> 
>>     1;
>> 
>> Note that attributes are not required on the test methods. Methods which start with "test_" are considered test methods (you can override this behavior, of course). That includes the test control methods of test_startup(), test_setup(), and so on.
>> 
>> You should be able to consume roles or use the rest of Moose any way you think you should.
>> 
>> Here's how we load and run tests:
>> 
>>     use Test::Class::Moose::Load qw(t/lib);
>> 
>>     Test::Class::Moose->new({
>>         # timing on a class and method level
>>         show_timing => 0,
>>         # how many classes, methods and tests
>>         statistics  => 1,
>>     })->runtests; 
>> 
>> My main concern is that the nested subtests will annoy people:
>> 
>>     # 
>>     # Executing tests for TestsFor::Basic::Subclass
>>     #
>>         # TestsFor::Basic::Subclass->test_me()
>>             ok 1 - I overrode my parent! (TestsFor::Basic::Subclass)
>>             1..1
>>         ok 1 - test_me
>>         # TestsFor::Basic::Subclass->test_this_baby()
>>             ok 1 - This should run before my parent method (TestsFor::Basic::Subclass)
>>             ok 2 - whee! (TestsFor::Basic::Subclass)
>>             1..2
>>         ok 2 - test_this_baby
>>         # TestsFor::Basic::Subclass->test_this_should_be_run()
>>             ok 1 - This is test number 1 in this method
>>             ok 2 - This is test number 2 in this method
>>             ok 3 - This is test number 3 in this method
>>             ok 4 - This is test number 4 in this method
>>             ok 5 - This is test number 5 in this method
>>             1..5
>>         ok 3 - test_this_should_be_run
>>         1..3
>>     ok 1 - TestsFor::Basic::Subclass
>>     # 
>>     # Executing tests for TestsFor::Basic
>>     # 
>>         # TestsFor::Basic->test_me()
>>             ok 1 - test_me() ran (TestsFor::Basic)
>>             ok 2 - this is another test (TestsFor::Basic)
>>             1..2
>>         ok 1 - test_me
>>         # TestsFor::Basic->test_this_baby()
>>             ok 1 - whee! (TestsFor::Basic)
>>             1..1
>>         ok 2 - test_this_baby
>>         1..2
>>     ok 2 - TestsFor::Basic
>>     1..2
>>     # Test classes:    2
>>     # Test methods:    5
>>     # Total tests run: 11
>>     ok
>>     All tests successful.
>>     Files=1, Tests=2,  2 wallclock secs
>>     Result: PASS
>> 
>> So, does this look useful for folks? Is there anything you would change? (It's trivial to assert plans for classes and the entire test suite rather than rely on done_testing(), but I haven't done that yet).
>> 
>> Cheers,
>> Ovid
>> --
>> Twitter - http://twitter.com/OvidPerl/
>> Buy my book - http://bit.ly/beginning_perl
>> Buy my other book - http://www.oreilly.com/catalog/perlhks/
>> Live and work overseas - http://www.overseas-exile.com/
>
>
>
>