[Dbix-class] helperrels vs basicrels

[Aran Deltac]

Thanks for the input Matt and Paul, good to know I'm on the right
track.  I'll fiddle around with these changes and see what I get to.
Once I have a more detailed plan I'll continue this thread and see if
everyone is happy with the changes.

Aran

On 5/14/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> 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
> suite.
>
> 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 :)
>
> _______________________________________________
> List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> Wiki: http://dbix-class.shadowcatsystems.co.uk/
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
>