Support data providers

[Ocramius]

Most of my slowest tests depend on dozens of test cases generated via data-providers: is there any way to reproduce those in some way when the data provider output is serializable?

[liuggio]

This could be an idea for the next version, having a deep phpunit integration,
but fastest now execute in processes in parallel.
In my team db fixtures are the slow part of the test, could you give an example how you use it?

[Ocramius]

I'll take a direct reference to a test here: https://github.com/Ocramius/ProxyManager/blob/ff246e7569744e4a15dc2b043777230d82813d2f/tests/ProxyManagerTest/Functional/FatalPreventionFunctionalTest.php#L89

This test takes all defined classes and throws them at a separate test (much like .phpt test cases) so that if fatals occur, the test suite doesn't crash.

In order to do that, a new process has to be spawned, and that takes an incredible amount of time for engines that are slower at booting up (hhvm, for example).

[liuggio]

Ehm this is an edge case - but -
if you use fastest and you create a singular functional test fore ach classes https://github.com/Ocramius/ProxyManager/blob/ff246e7569744e4a15dc2b043777230d82813d2f/tests/ProxyManagerTest/Functional/FatalPreventionFunctionalTest.php#L124

if a generator fails will broke only the process where that test run

[Ocramius]

@liuggio that still forces me to write code where the same test case applies multiple times.

For instance, a parallelized test may be reading data from various .csv files, or trying different DB connections (connection name provided by the data-provider). I don't really want to code additional classes for something that is indeed a test parameter.

I see that it's indeed problematic to implement support for something like that, but it would really be awesome :-)

[liuggio]

That's the adding value of fastest,
for each test fastest provides env parameters like echo getevn('ENV_TEST_CHANNEL');
that contains a different value per processor :)
or echo getevn('ENV_TEST_INC_NUMBER') that is the incremental id of the test.

[liuggio]

But yes I think there's no clean way to do this...