I’m sorry Dave, but you’re wrong, wrong, wrong! :]
The purpose of testing “attributes” is not to test that Moose did its thing. The purpose of testing attributes’ accessors is that they are part of your class’ interface. That an accessor is backed by a Moose attribute is an implementation detail. Just because
get_foo() is an attribute accessor today doesn’t mean that the data won’t be stored elsewhere in the future or even be derived from something else.
What you shouldn’t be doing is using
has_attribute_ok() from Test::Moose, again because where the data returned by the accessor is coming from shouldn’t matter to users of your class.
Ideas that I’ve got floating around, but which I haven’t gotten to yet:
- Like Pod::Coverage, but rather than looking at the symbol table, uses PPI to discover
subs that need documenting.
- Like Pod::Coverage, but, in addition to regular subroutines requiring documentation, reports on Moose generated accessors, delegations, etc. that are undocumented.
- Combines the two others.
Forgetting all the type constraint, role, and attribute handling that Moose does, I like it simply for what it’s contributed to documentation.
I’ve been using the constraint syntax for describing complicated data structures in POD and comments in cases where Moose isn’t actually involved. It’s nice to be able to simply state that a subroutine returns “ArrayRef[HashRef[Maybe[Str|HashRef[Foo::Bar]]]”. That’s a lot more comprehensible than a paragraph of description.
Moose Roles rock! I’m following Ovid‘s example and getting rid of inheritance in my code: nothing will inherit from anything. You’ll be able to tell what the code does without searching for a superclass’ superclass’ superclass.