Test::Stream UI discussion

[exodist]

This ticket is for discussion of the Test::Stream UI.

Right now Test::Stream is a loader. -Foo means load a bundle named Foo. Foo without a dash means load a plugin named Foo. :Foo means load a bundle from t/lib. Lowercase args are reserved by the loader. There are no defaults.

There were a couple reasons/goals in doing it this way:

1. I knew some people would not like the toolset I do (the V1 bundle) and I wanted it to be clear to all that ot was not the only way, and that they were not forced to use it. Before the current UI Test::Stream was what the V1 bundle is now.

2. The loader is inheritable if you want a custom test tool with defaults, or behavior specified for the lowercase options. this is something particularly useful for companies with complex testing needs.

3. The plugin/bundle system will hopefully prevent the kind of problems we hae with Test::Class which both adds behavior, and forces you to use Test::More a specific way.

4. bundles basically boil down to a list of arguments to the Test::Stream loader. This adds consistency.

I realized that it would not be hard to make it so that plugins and bundles could work without using the loader, that is make it work if they are used directly. I also realized some people would not like to use a loader. As a result I took some time and did it. As a result the loader is optional from a user perspective. However the loader is not truly optional since bundles still use it under the hood, users just don't see it.

[exodist]

Oops. Forgot another goal/morivation. The bundle system helps avoid lock-in while allowing a path forward. what I mean is that if we decide something in a set of tools is a bad idea we can deprecate the bundle and recommend a replacement. this means nothing breaks, we are not killing backcompat, but also we are able to put out something new and different for people to use from now on. This is something that can't be done with Test::More which is now more or less locked as it is because of back compat concerns.

[haarg]

I think the bundles are a decent idea, I just don't like Test::Stream functioning as a loader interface.

It adds an extra layer of indirection, making it less obvious where code is coming from. If I look at a test and see use Test::Stream::Bundle::Classic;, I know exactly where to look for documentation of what is provided. This also makes it easier to use automated tools like dependency scanners. An automated dependency scanner would see the actual bundle classes, meaning more accurate metadata. Having the bundles in metadata means you can move bundles into separate dists with less issues.

Test::Stream::Bundle is also a more natural place for the bundle handling to live than in Test::Stream.

The : bundle prefix seems like a misfeature. use lib 't/lib'; already handles this fine, without being more Test::Stream magic to learn.

The * option is more magic syntax that wouldn't be needed if the options weren't being combined into a single argument list, and it doesn't match how exports are handled elsewhere. If you did want * as an exporter option, it should be consistently supported.

The lower case options appear to just end up loading plugins. Again this seems to offer no advantages over loading the plugins directly.

[kentfredric]

And the Load a plugin syntax is really confusing if you don't know what its for and how it works.

You see use Test::Stream -V1, qw/Compare/; and your first question is "And what the hell do those do" ( where you have to consult a manual ).

You then find out "Compare" is a "plugin" and you have to understand what that means and how it works, and how Test::Stream is calling it and why.

When comparatively:

use Test::Stream::Bundle::V1;
use Test::Stream::Plugin::SRand;

Is perfectly obvious, you're requiring some modules and calling their import method, so you can work out what's happening by just looking in those modules for import related things.

Which is easy, because Exporting/Importing is basic perl knowledge.

The only reason Plugins are different from just any old Perl module, is that due to the bundle system needing a way to re-export things their plugins export, you have to have some kind of layer the bundler can call into to make that happen, and Exporter.pm can't do any of that.

But the user really doesn't have to care about that.

That's knowledge that is only relevant to people writing bundles.