[Dbix-class] helperrels vs basicrels

Matt S Trout dbix-class at trout.me.uk
Sun May 14 14:23:03 CEST 2006

Aran Deltac wrote:
> I've been working on writing a Manual POD about how testing works in
> DBIC.  The introduction of the document describes the reasoning:
> "Too many times I have heard on the mailing list and the #dbix-class
> IRC channel that people don't understand how the DBIx::Class testing
> framework works.  To be honest I was a bit perturbed myself the first
> time I tried to wade in to it.  The goal of this document is to give
> an overview of how the framework is setup, how you can add your own
> tests, and how you can apply a similar framework to your own
> distributions that use DBIx::Class."
> So, to that end, I have been going over the structure of how tests are
> written and how the whole structure works.  I've run in to one thing
> that I would like to have work differently.
> The difference between BasicRels and HelperRels seems unnecessary.  I
> could understand that back in the day, before there were helper
> methods for creating relationships, that you would have the BasicRels
> code which would call add_relationship as it currently does.  Then,
> the day came along when the higher level methods like belong_to and
> has_many were added and rather than remove the add_relationship code
> it was moved in to BasicRels and then HelperRels was created.  I think
> we are suitably past that day and that HelperRels tests the same thing
> as BasicRels, plus more, since behind the scenes HelperRels does the
> exact same thing BasicRels does.  BasicRels adds an added, yet
> unnecessary, level of complexity and maintanence headaches.

That's pretty accurate, although I'd note that there are some things the 
basicrels tests hit (uninflated foreign keys, notably) that aren't 
present in helperrels. I don't think there are many of these though and 
so they could probably be moved across easily enough.

> So, I want to ditch BasicRels and most of t/basicrels/*.  Then, move
> all the tests in t/helperrels/* to t/*.  Or, perhaps thats a bit messy
> and it would be better to just rename the helperrels/ folder to core/
> or some such.

Entirely in favour, provided some units tests are written that verify 
the has_one/has_many/etc. calls produce the appropriate add_relationship 
calls under the hood. At that point I'd say just t/*. We should also 
probably look at splitting up some of the bigger test scripts (01core 
and the join and relationships tests being the prime candidates) and 
maybe re-organising the rest somewhat - the current test split is very 
much evolved rather than architected which is, I think, also a major 
barrier to entry for people trying to add to them.

> In that vein - does anyone have anything on their wish list of things
> that they would like to change about how we test DBIC?

Get populate to support hashrefs as well as the current arrayref format 
and provide easy means to load the data from CSV and YAML ala 
ActiveRecord's fixtures, although we can't use that directly in the test 

The other big thing I'd like to see is the db-specific tests being 
largely dropped in favour of running the main test suite against any 
supported database (and before a release *every* supported database, 
with the likely exception of DB2/400 since I don't think any of us have 
an AS/400 handy to install it on :)

More information about the Dbix-class mailing list