You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey, I saw your talk, and I am convinced there is a use for Test2::Aggregate, specially when the goal is to "Just make tests faster". My only real complaint is one that applies to Test::Class, Test::Class::Moose, and a few others. You are implementing functionality that really should be part of the harness. Test2::Aggregate as well as the other packages I mention all work by getting between the harness and the test files in the form of writing a test file. Considering how Test::Harness works, I do not really blame these packages or their authors, writing a plugin for Test::Harness to use Test2::Aggregate to run the tests would be a royal pain.
Yath, Test2::Harness however is a lot more flexible. I am thinking it would be nice if Test2::Aggregate had a Test2::Harness plugin, one that would allow you to use it from yath without needing to write any .t files to live in the middle. Also the aggregate runs could further benefit from anything yath has already preloaded.
High level this is what I am thinking:
Yath would look for a # HARNESS-AGGREGATE-[GROUP] directive, similar to the other # HARNESS-XXX directives.
For every aggregate group defined in the test files yath would spawn a process to run all the tests aggregated, without forking/spawning for each one.
These tests would not be run separate from the aggregation.
The plugin would send the proper start/stop events between aggregated tests so that the harness just knows what events were from what test files.
an aggregate set would take a single job slot in the harness, so multiple aggregate sets could be run in parallel by yath
You could still support the current Test2::Aggregate style of writing .t files that aggregate other tests, the plugin would just be an alternate way to do it that avoid the need for them when using yath.
If you are interested let me know. My time is limited, but I would try to make time to support this if you wanted to take it on. The plugin could be a separate cpan dist, or it could be included in your Test2::Aggregate dist. I would also add a note referencing the plugin to the yath docs.
The text was updated successfully, but these errors were encountered:
Ah, I missed this, as it is on the company account and was only following mentions. Thanks for the interest, indeed it would make more sense for an aggregator to be part of the harness. I will do some research around it when I have time and let you know if I take the task on.
Hey, I saw your talk, and I am convinced there is a use for Test2::Aggregate, specially when the goal is to "Just make tests faster". My only real complaint is one that applies to Test::Class, Test::Class::Moose, and a few others. You are implementing functionality that really should be part of the harness. Test2::Aggregate as well as the other packages I mention all work by getting between the harness and the test files in the form of writing a test file. Considering how Test::Harness works, I do not really blame these packages or their authors, writing a plugin for Test::Harness to use Test2::Aggregate to run the tests would be a royal pain.
Yath, Test2::Harness however is a lot more flexible. I am thinking it would be nice if Test2::Aggregate had a Test2::Harness plugin, one that would allow you to use it from yath without needing to write any .t files to live in the middle. Also the aggregate runs could further benefit from anything yath has already preloaded.
High level this is what I am thinking:
# HARNESS-AGGREGATE-[GROUP]
directive, similar to the other# HARNESS-XXX
directives.You could still support the current Test2::Aggregate style of writing .t files that aggregate other tests, the plugin would just be an alternate way to do it that avoid the need for them when using yath.
If you are interested let me know. My time is limited, but I would try to make time to support this if you wanted to take it on. The plugin could be a separate cpan dist, or it could be included in your Test2::Aggregate dist. I would also add a note referencing the plugin to the yath docs.
The text was updated successfully, but these errors were encountered: