[Dbix-class] helperrels vs basicrels

[Aran Deltac]

I've created a branch off of -current for this work:

bast/branches/DBIx-Class/reorganize_tests/

I've made all of the changes discussed.  All tests pass, at least for
me.  Could someone take a gander and review my changes?  Here's the
highlights:

- Move DBICTest::Schema::HelperRels to DBICTest::Schema::Relationships.
- Move code in DBICTest::Setup to DBICTest::Schema, and separated it
in to two methods: $schema->auto_populate() and an override of
$schema->deploy().
- Remove DBICTest::Setup, DBICTest::HelperRels, DBICTest::BasicRels,
and DBICTest::Schema::BasicRels.
- Change the name of DBICTest::intialise() to init_schema(), which is
much more descriptive of what it happening, IMO.
- Removed all tests in t/helperrels/* (except 26sqlt.t) and t/basicrels/*.
- Modified all tests in t/run/* to:
     - No longer run within the run_tests() method.
     - Use DBICTest only, and call DBICTest::init_schema().
     - Database (mysql, pg, etc) tests no longer trigger creation and
population of the sqlite db.
- Moved all t/run/* tests to t/* and re-numbered them so that they
started at number 60, instead of 01.

I have two more things to do:

- Finish DBIx::Class::Manual::Testing document.
- Compare the dbic test coverage to the cdbicompat coverage to see if
there are any areas that cdbicompat tests which the dbic tests do not.
(per Matt's request)  If there are any discrepencies I'll write
corresponding dbic tests.

Aran


On 5/14/06, Aran Deltac <aran at arandeltac.com> wrote:
> 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/
> >
>