fREWdiculous!
7 Sep
I’ve taken care of a significant portion of the refactoring that I’m doing to disable meta-tests for the Moose test suite. I’ve done all the tests up until the 100 series (which are examples.) The following is an example of how it’s done:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 | #!/usr/bin/perl use strict; use warnings; use lib 't/lib'; use Test::More tests => 23; use Test::Exception; use MetaTest; { package Foo; use Moose; use Moose::Util::TypeConstraints; } skip_meta { can_ok('Foo', 'meta'); isa_ok(Foo->meta, 'Moose::Meta::Class'); } 2; meta_can_ok('Foo', 'meta', '... we got the &meta method'); ok(Foo->isa('Moose::Object'), '... Foo is automagically a Moose::Object'); skip_meta { dies_ok { Foo->meta->has_method() } '... has_method requires an arg'; dies_ok { Foo->meta->has_method('') } '... has_method requires an arg'; } 2; can_ok('Foo', 'does'); skip_meta { foreach my $function (qw( extends has before after around blessed confess type subtype as where coerce from via find_type_constraint )) { ok(!Foo->meta->has_method($function), '... the meta does not treat "' . $function . '" as a method'); } } 15; |
Typically there will be some skip_meta blocks scattered throughout a test. As it stands the skip_meta (and skip_all_meta variant) will skip if the SKIP_META_TESTS environment variable is set. As I said before, if people want to change that it’s only defined in one place so we can change how it’s done fairly easily.
There are a few places I’m not sure I need to skip yet, like things in the Moose::*::Meta namespace. But I know for sure to skip the ->meta stuff, so that’s what I’ve been doing. The 100 tests are quite a bit more complex, which is why I haven’t finished any yet. I certainly plan to, and hope to take care of them soon. But in the meantime mst can get started on Antlers as a good amount of the tests should work for him now.
If anyone wants to help out let me know, and we can make Moose faster sooner!
6 May
Sometimes when I get close to the end of the day and it isn’t feasible for me to start on something new I expand on my current project’s test suite. Recently I worked on one of the (seemingly) more complex ones. Basically it tests one of our autocompleters to ensure that it will search for the name and also the public facing id of a certain field. The id part was easy.
The name part was significantly more complex, but not too bad really:
1 2 3 4 5 6 7 8 9 10 11 | my @data = $schema->resultset('Customer')-> autocomplete_search({ query => 'ame' })->all; cmp_deeply @data, all( array_each( methods( name => re(qr/.*ame.*/i) ) ) ), "Name matches query"; |
So basically what that does is ensure that all of the items in @data have a method that match the regex listed. It doesn’t care how many items are returned or any of the other details. Elegance!
29 Apr
When I was writing WebCritic I decided that the code was small and simple enough that it would be a great candidate for me to figure out how to set up automated testing for the whole stack (except for the javascript.) This is something that I’ve wanted to do at work for a long time but I feel bad spending time figuring out stuff like this on the customer’s dollar. I already had Perl Testing: A Developer’s Notebook and I figured I’d use it to get a start. Very helpful!
Perl has some great testing modules out there, but the problem is finding which ones. We all know about Test::Simple, Test::More, and Test::Most. There are tons more though that can really help with testing. The book helped me find a lot of them.
But anyway, I decided that before I release my code, because I was doing some OO work, I might as well use Moose to do the OO parts (more on that later.) When I was doing the porting it was very helpful to have the tests there to tell me if I had done things correctly. This is one of the main reasons I have heard people use for creating a test suite. It is not necessarily that your code will magically be better, but that you can change code with abandon and know if you introduce new bugs. Of course this implies good test coverage, but I am not really at that point yet. I am just to the point where I have decided that testing is awesome!