Migrate tests to use DBIx::Class::EasyFixture

[preaction]

Having raw data directly in the test case is ugly and makes it harder to read. Instead, move the test fixtures into a class in t/lib that uses DBIx::Class::EasyFixture. Each table should have its own fixture, and proper dependencies should be set up using the next feature (so, the release_summary table requires data in the release_data table which requires data in the uploads and cpanstats tables).

This will make it easier to read and write tests.

[jkeenan]

In the first issue you refer to "the test case" -- a wording I read as implying that there is only one such test case. But I see that there are currently 5 test files in the distribution:

$ find t -type f -name '*.t'
t/legacy/metabase.t
t/api.t
t/controller/upload.t
t/controller/report.t
t/controller/summary.t
t/controller/release.t

Can you be a bit more specific as to which data needs replacing?

Thank you very much.
Jim Keenan

[preaction]

the test case refers to each test case that has data inside of it instead of in a central place for easier access. Most of the data inside those test cases is duplicated between the tests to set up the relationships that must exist for valid data in the database. So, in short, all of them.

In an ideal world, I would ask for the specific piece of data my test needs to be created, and all the required dependent data would be created automatically. Right now, DBIx::Class::EasyFixture seems the closest to that: It allows to define named fixtures that can depend on other fixtures, manually building a set of relationships in the available set of test data.

However, using DBIx::Class::EasyFixture moves the data being tested far away from the tests being run on that data, requiring a developer to look in two places to see what's happening. If you've got some ideas on how to fix that limitation, I'm definitely open to it. But, for now, making it easier to write tests with known data will be helpful.