On Sat, Mar 6, 2010 at 11:42 PM, Chad Granum <span dir="ltr"><<a href="mailto:exodist7@gmail.com">exodist7@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">Ingy,<br>
<br>
I like parts of what your suggesting. My goal is to make Fennec very<br>
flexible. I am thinking it may be possible to write a plugin for<br>
TestML and Fennec to work together. After I have Fennec to a point<br>
where I consider it usable would you be interested in working with me<br>
to work in support for TestML test files?</div></div></blockquote><div><br>Absolutely. I'll keep my eyes on Fennec as well.<br>
<br>
Cheers, Ingy<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="h5">I will continue on from here<br>
keeping in mind that I might want to support test files from TestML in<br>
the future.<br>
<br>
Thank you.<br>
<br>
-Chad<br>
<br>
On Sat, Mar 6, 2010 at 11:25 PM, Ingy dot Net <<a href="mailto:ingy@ingy.net">ingy@ingy.net</a>> wrote:<br>
> Chad,<br>
><br>
> I just wanted to add that I started TestML (see <a href="http://www.testml.org" target="_blank">http://www.testml.org</a>) about<br>
> a year ago. It is a unit testing language for all programming languages. You<br>
> write tests in TestML and then write your software in any language. It is<br>
> inspired by FIT, but not tied to a weird tabular harness like FIT. (In fact<br>
> it's not even tied to any harness in a given language. It just needs a<br>
> Runner subclass to tie it to a given harness/testing framework. So far I<br>
> have implementations in Perl and Python. It's still in its infancy.)<br>
><br>
> My main reason for starting TestML is that I believe programmers need to<br>
> start writing modules that can be used in many programming languages. If<br>
> they can pass the same test suite, that is something of an insurance that<br>
> they truly are the same. I think think is critical for modules that get<br>
> ported from Perl5 to Perl6. Wouldn't you want both versions to pass the same<br>
> tests?<br>
><br>
> I believe that great programmers should share their ideas (in code) with all<br>
> people, not just the people in their language. I call this belief Acmeism<br>
> (because I think that good ideas need a name). I am also working on a new<br>
> programming language called C'Dent that lets modules be compiled to from<br>
> your language to a dozen or more others.<br>
><br>
> Acmeism is fueled by the weird feeling I get at conferences like OSCON and<br>
> OSDC where great programmers of many languages come together to one place at<br>
> one time, only to go off to their own corners and talk about their own<br>
> things. None of these languages is so good that it's going to make the<br>
> others obsolete. So why not work on things above the language level?<br>
><br>
> I would encourage anyone as brave as you, for starting a new technology<br>
> movement, to think bigger than Perl. Think as big as you can.<br>
><br>
> Respectfully, Ingy döt Net<br>
><br>
> On Thu, Mar 4, 2010 at 7:10 PM, Chad Granum <<a href="mailto:exodist7@gmail.com">exodist7@gmail.com</a>> wrote:<br>
>><br>
>> Recently there have been a couple movements to 'modernize' parts of<br>
>> perl. Two immediate examples are Moose which is a more modern OO<br>
>> system (like perl6), the other is perl5i which Schwern is heading.<br>
>> perl5i is intended to fix all kinds of gripes. Thus far I have not<br>
>> seen any similar movement in the area of perl testing. After a<br>
>> discussion which compared and contrasted perl's testing tools with<br>
>> another set of test tools it occurred to me that there is probably<br>
>> room for significant improvement. I have decided to try to fill this<br>
>> void in modernization of perl testing.<br>
>><br>
>> I have started the fennec project (<a href="http://github.com/exodist/Fennec" target="_blank">http://github.com/exodist/Fennec</a>)<br>
>> before the name scares you let it be known that the original name was<br>
>> to be Test::Suite, and I have just obtained that namespace (it was<br>
>> previously owned by someone else) so the name may change back.<br>
>><br>
>> I am requesting that anyone and everyone put there 2 cents in on what<br>
>> is amazing, good, bad, ugly, or impossible with the current perl<br>
>> testing tools. How they can be improved, etc. I also encourage anyone<br>
>> interested to add issues, look for bugs, add feature requests, submit<br>
>> patches, fork the repo, etc.<br>
>><br>
>> Here is a simple bulleted list of desired features, most of these have<br>
>> a current (bu maybe in need of improvement) implementation.<br>
>><br>
>> * Group tests into sets which can be run multiple times under<br>
>> different scenarios<br>
>> * Every test file should create an object that is run<br>
>> * Test sets should be run in random order by default, as should cases<br>
>> (scenarios) and even test files.<br>
>> * Writing tester function libraries (think Test::More,<br>
>> Test::Exception, etc) should be very simplified<br>
>> * Test results should be reported to the tester in object form,<br>
>> unlike Test::Builder which just outputs any results directly to TAP.<br>
>> * Ability to create result handlers for cases where you want to get<br>
>> results directly instead of going straight to TAP.<br>
>> * TAP output plugin used by default<br>
>> * Database output plugin (record results to a simple database)<br>
>> * Test::Builder output plugin (If you really want to go through<br>
>> Test::Builder, this is also the first output plugin for quickstart of<br>
>> the project)<br>
>> * Ability to use multiple output plugins at once.<br>
>> * Ability to wrap existing Test::Builder plugins (like Test::More)<br>
>> into Fennec tester libraries (this is already done for Test::More,<br>
>> Test::Warn)<br>
>> * Ability to run just a specified case/set<br>
>> * More helpful output in some current testers (is_deeply for example)<br>
>> * Ability to define tests both in separate files, and inline with the<br>
>> objects being tested<br>
>> * When not in testing mode these definitions should be ignored and<br>
>> minimal overhead should occur as a result of their being present.<br>
>> * Inline tests are purely optional<br>
>> * Perhaps tests be defined after __END__?<br>
>><br>
>> Test result objects need to contain the following information:<br>
>> * Name,<br>
>> * Result (ok, not ok),<br>
>> * Case run under,<br>
>> * Set run under,<br>
>> * Line tester was called from,<br>
>> * File tester was called from,<br>
>> * todo (false or reason),<br>
>> * skip (false or reason),<br>
>> * diagnostics messages,<br>
>><br>
>> Defining tests and cases should be moose like:<br>
>><br>
>> case name => sub {};<br>
>> case name => (<br>
>> code => sub {},<br>
>> partition => 'name',<br>
>> ..options..,<br>
>> );<br>
>> set name => sub {};<br>
>><br>
>> Tests should also be definable by creating subs prefixed with 'test' or<br>
>> 'case'<br>
>> sub test_something {}<br>
>> sub case_prepare_things {}<br>
>><br>
>> There will also be an init method that will be called just once prior<br>
>> to running the cases.<br>
>><br>
>> The base principal for Fennec is that test will be grouped into sets,<br>
>> each of these sets can be run against multiple cases. Essentially a<br>
>> case is a method on a test object you define that creates a scenario,<br>
>> once the scenario is ready all your test sets will be run under that<br>
>> scenario, once the sets are all completed the next scenario will be<br>
>> run and the sets will be run again. You can mark an entire case or set<br>
>> as todo or skip. You also can also specify that sets should only run<br>
>> under certain cases, or not under others. You can also group sets and<br>
>> cases into a 'partition' so that only sets in that partition will be<br>
>> run under the cases in the same partition.<br>
>><br>
>> Currently there are 2 types of plugins, output plugins which take<br>
>> results and do stuff with them, and tester plugins with provide<br>
>> functionality such as ok, like, is, diag, etc.<br>
>><br>
>> I appreciate any feedback anyone wants to provide!<br>
>><br>
>> -Chad Granum<br>
>> _______________________________________________<br>
>> Pdx-pm-list mailing list<br>
>> <a href="mailto:Pdx-pm-list@pm.org">Pdx-pm-list@pm.org</a><br>
>> <a href="http://mail.pm.org/mailman/listinfo/pdx-pm-list" target="_blank">http://mail.pm.org/mailman/listinfo/pdx-pm-list</a><br>
><br>
><br>
_______________________________________________<br>
Pdx-pm-list mailing list<br>
<a href="mailto:Pdx-pm-list@pm.org">Pdx-pm-list@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/pdx-pm-list" target="_blank">http://mail.pm.org/mailman/listinfo/pdx-pm-list</a><br>
</div></div></blockquote></div><br>