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

Re: [extremeperl] Perl, OOP, and Unit Testing

Expand Messages
  • Rob Nagler
    ... For practical reasons, we manage all data through classes. This simplifies the calling convention (we always use - when calling an API). Classes can
    Message 1 of 4 , Jul 22, 2002
    • 0 Attachment
      asimjalis writes:
      > The test instead of defining the OO interface
      > should define the data structure.

      For practical reasons, we manage all data through classes. This
      simplifies the calling convention (we always use -> when calling an
      API). Classes can return rich data structures a la XML::Parser, which
      are not objects. This feels "right" to me in Perl. The test still
      tests the OO API. The result check may have to validate a rich data
      structure, which is easy in Perl thanks to ref() and defined().

      I (and others [1]) agree with your conclusions about OO and data.
      Fine grained objects are a big problem in Java, which is why int,
      boolean, etc. are not objects (and therefore can't be NULL, which is
      another problem :-). This is why Java sucks in many ways. Arrays and
      hashes are very cumbersome to use, but they are necessary to solve
      most problems in software.

      A good example of "unnecessary OO" is XML Data Binding[2]. In Java,
      you need some way to access XML data efficiently. XPath-like
      interfaces aren't it. Data Binding allows you to instantiate an XML
      file as a set of classes generated from the DTD. You don't need this
      in Perl, because you have everything you need with hashes and arrays.
      This makes Perl's XML handling more efficient and easier to use.

      My #1 goal in testing is to have a test case per line. I find
      declarative testing is the easiest way to do this. It also gives more
      control to the test framework. To me, it's completely natural and
      easy to write declarative tests in Perl. In Java it's cumbersome,
      because it lacks simple data structures like lists. Can't say for
      Python.

      Cheers,
      Rob

      [1] http://www.paulgraham.com/noop.html
      [2] See http://www.rpbourret.com/xml/XMLDataBinding.htm and
      http://java.sun.com/xml/jaxb/ and
      http://java.sun.com/xml/jaxb/jaxb-docs.pdf
    • Asim Jalis
      Hey Rob, ... What do you mean by declarative tests ? Could you give an example? Asim __________________________________________________ Do You Yahoo!? Yahoo!
      Message 2 of 4 , Jul 22, 2002
      • 0 Attachment
        Hey Rob,

        > My #1 goal in testing is to have a test case per
        > line. I find declarative testing is the easiest
        > way to do this. It also gives more control to the
        > test framework. To me, it's completely natural
        > and easy to write declarative tests in Perl. In
        > Java it's cumbersome, because it lacks simple data
        > structures like lists. Can't say for Python.

        What do you mean by "declarative tests"? Could you
        give an example?

        Asim


        __________________________________________________
        Do You Yahoo!?
        Yahoo! Health - Feel better, live better
        http://health.yahoo.com
      • Rob Nagler
        ... A declarative language allows you to specify your intent and the interpreter executes the program in whatever order it sees fit. SQL is a declarative
        Message 3 of 4 , Jul 23, 2002
        • 0 Attachment
          Asim Jalis writes:
          > What do you mean by "declarative tests"? Could you
          > give an example?

          A declarative language allows you to specify your intent and the
          interpreter executes the program in whatever order it sees fit. SQL
          is a declarative language. Here's a declarative test:

          use strict;
          use Bivio::Test;
          use Bivio::Type::Integer;
          use Bivio::TypeError;
          Bivio::Test->unit([
          'Bivio::Type::Integer' => [
          get_min => -999999999,
          get_max => 999999999,
          get_precision => 9,
          get_width => 10,
          get_decimals => 0,
          can_be_zero => 1,
          can_be_positive => 1,
          can_be_negative => 1,
          from_literal => [
          ['9'] => [9],
          ['+00009'] => [9],
          ['-00009'] => [-9],
          ['x'] => [undef, Bivio::TypeError->INTEGER],
          [undef] => [undef],
          [''] => [undef],
          [' '] => [undef],
          ['-99999999999999'] => [undef, Bivio::TypeError->NUMBER_RANGE],
          ['-00000000000009'] => [-9],
          ['+00000000000009'] => [9],
          ['-999999999'] => [-999999999],
          ['+999999999'] => [999999999],
          ['+1000000000'] => [undef, Bivio::TypeError->NUMBER_RANGE],
          ['-1000000000'] => [undef, Bivio::TypeError->NUMBER_RANGE],
          ],
          ]]);

          This test is compiled by Bivio::Test->unit first. This generates the
          standard 1..n header for Perl tests. It also outputs ok/not ok.
          Catches exceptions and so on. All I need to do is declare the
          relationships between API calls and values. I don't particularly care
          what order the tests are executed in or *how* it executes them. I
          only care that *what* Bivio::Test->unit executes is as I have defined
          it.

          Rob
        Your message has been successfully submitted and would be delivered to recipients shortly.