Loading ...
Sorry, an error occurred while loading the content.

409Re: [extremeperl] unit tester

Expand Messages
  • Adam Sroka
    Aug 29, 2005
      Rob Nagler wrote:

      >Here's a simple comparison:
      > use strict;
      > use Test::More tests => 5;
      > use Test::Exception;
      > BEGIN {
      > use_ok('EMA');
      > }
      > dies_ok {EMA->new(-2)};
      > dies_ok {EMA->new(0)};
      > lives_ok {EMA->new(1)};
      > dies_ok {EMA->new(2.5)};
      >in Bivio::Test this would be:
      > use strict;
      > use Bivio::Test;
      > Bivio::Test->new('EMA')->unit([
      > EMA => [
      > new => [
      > -2 => Bivio::DieCode->DIE,
      > 0 => Bivio::DieCode->DIE,
      > 1 => undef,
      > 2.5 => Bivio::DieCode->DIE,
      > ],
      > ],
      > ]);
      You make several good points, but it seems to me like you are throwing
      out the baby with the bath water.

      I never declare the number of units. A "best practice" to someone is a
      silly, waste of time to someone else. However, instead of writing my own
      test framework:

      use Test::More qw(no_plan);

      Works just fine for me.

      I don't like use_ok() that much either. Since I am test driving, it is
      enough that the test fails if it can't find the class under test. This
      will not compile ("Can't locate Does_Not_Exist.pm in @INC..."):

      use strict;
      use warnings;
      use Does_Not_Exist;

      That works for me too. I suppose I like it because it is the same way I
      would do it in another language like Java (or C#). This doesn't compile
      in Java:

      import org.testng.annotations.*;
      import org.obnoxiously.long.package.name.DoesNotExist;

      public class StuffTest {

      The semantic difference between your code snippets above seems to be
      that you are encapsulating your unit tests in an object. If you come
      from an xUnit language like Smalltalk, Java, or C#, then you do this
      because you have no choice (Everything HAS to be encapsulated by an
      object in those languages.) Since we don't HAVE to do that, the question
      becomes, why would we want to? I wouldn't. You'll have to explain why
      you would.

      I wouldn't because I think that the nature of testing is procedural, so
      testing procedurally until I have an idea that smells like an object
      feels like the right thing to do. Once I have an idea that feels like it
      needs to be an object, then I make one. That is the essence of XP - do
      the simplest thing that could possibly work. Most unit tests in other
      languages feel like procedures wrapped in classes anyway (e.g. TestCase
      feels more like a collection of testThis() methods than a proper class.)

      Your code is every bit as repetitive as the code you are replacing. The
      difference is that you've dropped in a layer of abstraction
      (unnecessarily, IMO) between your repetitive test code and the main
      package. Test code is repetitive because testing is repetitive. You can
      hide that, but you haven't changed it.
    • Show all 33 messages in this topic