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

Re: [extremeperl] unit tester

Expand Messages
  • Rob Nagler
    ... There are two purposes for writing tests: TDD and regression. TDD is great, but the real value pays off when a test fails b/c of an unknown implicit
    Message 1 of 33 , Aug 31, 2005
    • 0 Attachment
      Adam Sroka writes:
      > I am doing TDD, I know what I am testing.

      There are two purposes for writing tests: TDD and regression. TDD is
      great, but the real value pays off when a test fails b/c of an
      unknown implicit coupling.

      We have 300 unit tests with 16KLOC and 250 acceptance test with
      27KLOC. Our code base is 660KLOC (approx 200KNCLOC in 15K subs) in 3K
      classes and 64KLOC in 1K bview files. All of this code is in
      production, and it undergoes daily acceptance tests on our test
      systems, whether we are actively developing or not. If a test fails,
      we have to fix the problem.

      We have had about 200 releases of bOP in the last 4 years. All of
      these systems use bOP, and changes to the infrastructure are the
      primary reason for failures. TDD helps you for a few minutes while
      you add a feature. Regression testing helps you the rest of the
      system's life.

      We don't know what is going to break or why with regression testing.
      If I kept that much in my head, I'd go crazy. However, at any point,
      I might have to work on any one of these systems, and that's why we
      use a highly refactored shared app framework. I'd go crazy trying to
      figure out the problem if every system duplicate the concepts in bOP.

      > Hmm... three different tests, three different method calls. Makes sense
      > to me. Your approach is still performing three different tests, but you
      > are HIDING this fact in your implementation. IMHO, your approach is LESS
      > clear.

      Absolutely! Refactoring is all about information hiding.

      > As for the issue of state, if $ema has some state that is
      > maintained from one invocation to the next the test should make that
      > clear. The way the test is written does not call for any state,
      > therefore you shouldn't implement any. If you do, you are NOT doing TDD.

      $ema is a variable; it is state.

      > I think you are taking the idea of duplication a little too far.

      You aren't the first person to say this to me. :-)

      > Duplication is okay when it conveys something useful. For example, if I
      > have three things to test I write three tests. It is clear to everyone
      > who reads my test code that it contains three tests. This is a good
      > thing.

      Well, since we differ on our core values, we aren't going to agree on
      the details.

      > Since I am using Test::* packages from CPAN, I am fairly sure that the
      > framework is well shared. I am also pretty sure that other perl
      > programmers will understand the tests I have written. As for naming, I
      > keep my test files small, one per thing (Class, Package, Script, etc.)
      > under test. I also keep my fixtures in the smallest lexical scope
      > necessary.

      That's good sense, but most of CPAN is very buggy. It contains lots
      of duplicated bugs in duplicated interfaces. That's the nature of the
      beast. I love CPAN, but I also wrap almost every CPAN module if I use
      it more than once.

      > 1) it doesn't encapsulate any data

      Tests encapsulate data.

      > 2) if there is no data, then there is no behavior associated with that data

      If there is no data and there is no behavior, exactly what does the
      test do? A program is a function (behavior) over state (data) and
      time. Tests validate the output of the function.

      > 3) in fact, test is a behavior the result of which is true or false
      > (pass or fail). It takes data (The thing to test) and returns a result.
      > It is a function/method/procedure not a class. Forcing "Test" to be a
      > class is a kludge, IMO.

      Our goal with unit tests is that they specify the (input, output)
      tuple and the name of the API, and nothing more. The name, as I have
      pointed out earlier, is a "file" (class) and a entry point (sub)
      within that file. That's called "definitional declarative
      programming" (as opposed to functional declarative among others).
      That's our goal, anyway. In reality, the inputs are complex and
      require functions to set them up. We encapsulate those functions when
      we have duplication, but there's still more code in our unit tests
      than I would like.

      Rob
    • Dave Cross
      ... You didn t get a reply to this. I hope this isn t too late to be useful. prove is a command line test runner. It s included with recent versions of
      Message 33 of 33 , Sep 14, 2005
      • 0 Attachment
        Terrence Brannon wrote:
        > Adam Sroka <adam.s@...> writes:
        >
        >
        >>I just use Test::More and prove.
        >
        >
        > what is prove? I could not find it in the main Test::More docs:
        >
        > http://search.cpan.org/~mschwern/Test-Simple-0.60/lib/Test/More.pm

        You didn't get a reply to this. I hope this isn't too late to be useful.

        prove is a command line test runner. It's included with recent versions
        of Test::Harness.

        http://search.cpan.org/dist/Test-Harness/

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