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

Re: What to test

Expand Messages
  • Laurent Bossavit
    ... Are you writing that using Test Driven Development ? Easy to write is one feature of unit tests, but not the only distinguishing feature. So you ve
    Message 1 of 4 , Nov 5 1:05 AM
    • 0 Attachment
      "C." :

      > We are working on an object that figures out interclass dependencies
      > (not unlike JDepend) .The public interface looks something like this: [...]
      > It is easy to write unit tests for this.

      Are you writing that using Test Driven Development ?

      "Easy to write" is one feature of unit tests, but not the only
      distinguishing feature.

      So you've written a test which references an existing class and
      checks the dependency computation against a list of known
      dependencies, like so :

      Class knownClass = KnownClass.class;
      List dependencies = getDependencies(knownClass);
      assertListEquals( {String.class, List.class, ...}, dependencies);

      The next question is always, "Is the implementation obvious ?"

      If the implementation is obvious, or very nearly so, you have indeed
      written a unit test. You write the small bit of code that makes it
      pass and go on to the next obvious test and obvious implementation.

      Whenever you have a test for which the implementation is not obvious,
      Test Driven Development suggests that you break it down into smaller
      tests. You comment out (or delete) the original big test, and write a
      smaller test - for instance one for parse().

      In Test Driven Development, it is your tests which drive the "public
      interface". You don't start out with a public interface already
      specified then write tests against that interface; rather, you write
      a very simple test, for which writing the implementation should be
      obvious, and the test suggests the interface of an object.

      I see an indication in your above comment which suggests that the
      size of test that you have already considered makes them "functional
      tests" rather than "unit tests"; you're saying "This is somewhat like
      JDepend" - if you were writing this as a product for a customer the
      test above would be the customer test for the user story "Parse class
      dependencies resulting from method signatures", for instance.

      In fact, working from the sample test above, we could easily end up
      with a customer test framework which used a Java source file and a
      text file with the list of dependencies as input files.

      My other computer is also a Cray.
    Your message has been successfully submitted and would be delivered to recipients shortly.