Consider using TestML instead of Test::Base.

[ingydotnet]

Test::Base is deprecated in favor of TestML. Same data language.

I'll get it started on the TestML branch.

Note that like Test::Base, you can use TestML for just some of the tests. Therefore Test{::Base,ML} can live side by side during the transition.

[agentzh]

@ingydotnet Wow. that sounds awesome :)

[agentzh]

@ingydotnet I was really missing the filters syntax while reading through the TestML specification.

[ingydotnet]

@agentzh can you give me an example?

[agentzh]

@ingydotnet For specifying contents of special characters or long contents of repeated pattern, for example,

--- response_body eval
"Hello\r\n"

and

--- response_body eval
"abc" x 4096

There're other commonly used filters like chomp.

Another things is that Test::Nginx::Socket exposes configuration subs like repeated_each, no_long_string, no_diff, worker_processes, no_shuffle, and etc:

https://metacpan.org/pod/Test::Nginx::Socket#Exported-Perl-Functions

I've been wondering about their counterpart in TestML.

[ingydotnet]

@agentzh sorry for the late reply. I made this for you: https://gist.github.com/f7bde68247a8318f3a6d

I think that covers your needs. If you want to have a bunch of reusable filters, just make a bridge base class for that.

Find me on IRC if you need to.

[agentzh]

@ingydotnet So TestML still does not support the filter syntax of Test::Base? I've found the filter syntax handy in cases that different test blocks in a test file can use different settings of filters (or none at all).

[ingydotnet]

@agentzh You don't specify the filters on the data point definitions anymore. You specify them in the testml imperative code lines. I think this is more explicit and flexible too.

Instead of:

*foo == "BAR"
=== Test 1
--- foo upper
bar

Just do:

*foo.upper == "BAR"

=== Test 1
--- foo
bar

You still have the upper filter. Just goes in the code section instead of the data section.

I could add filter calls to the data section, but I don't see that it would be an improvement.

Pinged you on freenode IRC, btw.

[agentzh]

@ingydotnet The code line approach makes the filter setting global in the test file, which is not really desired. In many of my test files, I just want to enable filters selectively on some test blocks that really need them. But yeah, global filter application is useful for its own right, but IMHO it's not sufficient :)

I'll try logging into the IRC :P

[ingydotnet]

@agentzh I can add per block filters to TestML, but I think you can get by without them in the interim. Can you send me a real life example of where these would be needed?

[agentzh]

@ingydotnet For example, some blocks contain special characters like /r but some blocks don't. So it's desirable to use the eval filter only on those really need it. The same apples to other filters like chomp.

[ingydotnet]

@agentzh I finally figured out why block level transforms (filters) are needed.

This is a bogus example, but the point is that you want to test blocks that have been coerced in different ways to be in the same form when you test them:

*code.dump == *json.load.dump
=== Python
--- code.python_eval
{foo: 42}
--- json
{"foo": 42}
=== Perl
{foo->42}
-- json
{"foo": 42}

[ingydotnet]

If I do this, I think that the filters should follow the point names using dots:

--- code.chomp.eval

Also if I need to support filter args, it will be harder to implement:

--- xxx.filter1('abc')

[ingydotnet]

Also, Test::Base was Perl specific, but TestML isn't really. I'm debating whether to make a standard filter library, or just let other people make them.

[agentzh]

@ingydotnet I like the new per-section filter syntax :)

Regarding the standard filter library for TestML, maybe just implement language-agnostic filters, like chomp and chop? The eval filter is not really portable anyway :)

Thanks!