Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Monday, September 26, 2016

MODULES FOR XUNIT TESTING IN PERL

Test::Class : "MODULES FOR XUNIT TESTING IN PERL"



'via Blog this'



Not a bad summary:



Test::Unit is a port of JUnit into Perl.  Familiar to xUnit users.



Test::Class

Much like xUnit.  xUnit inspired. Unfamiliar names muck up porting, but can live with that.

Plays well with traditional Perl test tools like TAP and Test::Builder.

Somewhat object oriented.  But

 Test::Class does not provide its own test functions, but uses those provided by Test::More and friends 
which are free functions, so somewhat annoying to extend (e.g. to report error location accurately, when you build meta-tests that call multiple asserts internally). But you can access the underlying Test::Builder routines.

Uses :Test attribute so that introspection can find test functions to rub, including setup/teardown.

Pleasant - many folks have had to add such "keep running" behaviour to xUnit.

Unlike JUnit the test functions supplied by Test::More et al do not throw exceptions on failure. They just report the failure to STDOUT where it is collected by Test::Harness. This means that where you have
sub foo : Test(2) {
      ok($foo->method1);
      ok($foo->method2);
      ok($foo->method3) or die "method3 test failure";
      ok($foo->method4);
  }

The second test will run if the first one fails But the third will stop the fourth from running.
Test::Unit

Test::Unit is a port of JUnit http://www.junit.org/ into perl. If you have used JUnit then the Test::Unit framework should be very familiar.

It is class based so you can easily reuse your test classes and extend by subclassing. You get a nice flexible framework you can tweak to your heart's content. If you can run Tk you also get a graphical test runner. However, Test::Unit is not based on Test::Builder. You cannot easily move Test::Builder based test functions into Test::Unit based classes. You have to learn another test assertion API.

Test::Unit implements it's own testing framework separate from Test::Harness. You can retrofit *.t scripts as unit tests, and output test results in the format that Test::Harness expects, but things like todo tests and skipping tests are not supported.


But... the Test::Case author does not say that Test::Unit is mostly abandoned as odf 2016, possibly since 2011 or before.  

Test::SimpleUnit

A very simple unit testing framework. If you are looking for a lightweight single module solution this might be for you. The advantage of Test::SimpleUnit is that it is simple! Just one module with a smallish API to learn. Of course this is also the disadvantage.

It's not class based so you cannot create testing classes to reuse and extend. It doesn't use Test::Builder so it's difficult to extend or integrate with other testing modules. If you are already familiar with Test::BuilderTest::More and friends you will have to learn a new test assertion API. It does not support todo tests.

MODULES FOR XUNIT TESTING IN PERL

Test::Class : "MODULES FOR XUNIT TESTING IN PERL"



'via Blog this'



Not a bad summary:



Test::Unit is a port of JUnit into Perl.  Familiar to xUnit users.



Test::Class

Much like xUnit.  xUnit inspired. Unfamiliar names muck up porting, but can live with that.

Plays well with traditional Perl test tools like TAP and Test::Builder.

Somewhat object oriented.  But

 Test::Class does not provide its own test functions, but uses those provided by Test::More and friends 
which are free functions, so somewhat annoying to extend (e.g. to report error location accurately, when you build meta-tests that call multiple asserts internally). But you can access the underlying Test::Builder routines.

Uses :Test attribute so that introspection can find test functions to rub, including setup/teardown.

Pleasant - many folks have had to add such "keep running" behaviour to xUnit.

Unlike JUnit the test functions supplied by Test::More et al do not throw exceptions on failure. They just report the failure to STDOUT where it is collected by Test::Harness. This means that where you have
sub foo : Test(2) {
      ok($foo->method1);
      ok($foo->method2);
      ok($foo->method3) or die "method3 test failure";
      ok($foo->method4);
  }

The second test will run if the first one fails But the third will stop the fourth from running.
Test::Unit

Test::Unit is a port of JUnit http://www.junit.org/ into perl. If you have used JUnit then the Test::Unit framework should be very familiar.

It is class based so you can easily reuse your test classes and extend by subclassing. You get a nice flexible framework you can tweak to your heart's content. If you can run Tk you also get a graphical test runner. However, Test::Unit is not based on Test::Builder. You cannot easily move Test::Builder based test functions into Test::Unit based classes. You have to learn another test assertion API.

Test::Unit implements it's own testing framework separate from Test::Harness. You can retrofit *.t scripts as unit tests, and output test results in the format that Test::Harness expects, but things like todo tests and skipping tests are not supported.


But... the Test::Case author does not say that Test::Unit is mostly abandoned as odf 2016, possibly since 2011 or before.  

Test::SimpleUnit

A very simple unit testing framework. If you are looking for a lightweight single module solution this might be for you. The advantage of Test::SimpleUnit is that it is simple! Just one module with a smallish API to learn. Of course this is also the disadvantage.

It's not class based so you cannot create testing classes to reuse and extend. It doesn't use Test::Builder so it's difficult to extend or integrate with other testing modules. If you are already familiar with Test::BuilderTest::More and friends you will have to learn a new test assertion API. It does not support todo tests.