Skip navigation

Tag Archives: Moose

Test Moose accessors? Hell, yes.

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.

Dear LazyCPAN, please create these documentation modules.

Ideas that I’ve got floating around, but which I haven’t gotten to yet:

Pod::Coverage::PPI
Like Pod::Coverage, but rather than looking at the symbol table, uses PPI to discover subs that need documenting.
Pod::Coverage::Moose
Like Pod::Coverage, but, in addition to regular subroutines requiring documentation, reports on Moose generated accessors, delegations, etc. that are undocumented.
Pod::Coverage::PPIMoose
Combines the two others.

Moose as documentation.

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.

Eliminating all inheritance from my code.

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.