Should shut kwalitee up: http://cpants.cpanauthors.org/dist/DBIx-Class
and run the passing tests as real tests.
Almost 7 years ago a refactor in fea3d04 fed an (undocumented) $attrs parameter from new_related() to new_result(), while new_result() never expected (and ignored) said parameter. Since this is an undocumented feature, which nobody complained about for all this time - document extensively and kill it with fire.
…kouts) This is an interim solution and is by no means the final thing. It simply was possible to do in a short timeframe and cuts the test run time in half. If you have DSN envvars set, use at least -s -j8 for best results (the shuffling un-bunches similar tests, see discussion below) Two things are at play: First of all every SQLite database and every temp work directory is created separately using the pid of the *main* test process (there can be children) for disambiguation. Extra cleanup passes have been added to ensure t/var remains clean between runs. All other DSNs are reduced to their ->sqlt_type form and the result is used for a global lockfile. Said lockfile is kept in /tmp so that multiple testruns from multiple directories can be run against the same set of databases with no conflicts. Some of the tests are explicitly exempt from any locking and will run regardless of environment, for example t/storage/dbi_env.t The lockfiles are deliberately placed in File::Spec->tmpdir. This is done so that multiple dbic checkouts can run against the same set of DSNs without stepping on each other's toes. Some notes on why this is not a great idea, even though it works flawlessly under continuous test cycling: The problem is that our tests are not yet ordered in a spwecific way. This means that multiple tests competing for the same resource will inevitably lock all available test threads forming several bottlenecks along the path of execution. This issue will be adressed in a later patch, with the following considerations: - prove -l t/... must continue to work as is - test aggregation is something the test suite should try to avoid in general - after all DBIC is intended to be usable in CGI (yes, pure CGI) environments, so if the tests are getting heavy to run - this is an actual problem in need of fixing. Aggregation will instead sweep it under the rug - general reorganization of test groups / various path changes should only be attempted once we have a solid base for multi-db test runs
In order to do this during testing only introduce the ::_ENV_::DBICTEST macro, and also make sure DBICTest::RunMode is loaded before the macro is set (therefore the multiple test changes)
…- it seems to pass fine now