Re: Coding inside the debugger

From: Michael Feathers (mfeathers_at_objectmentorNOSPAM.com)
Date: 08/22/04

  • Next message: Richard Riehle: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management" 
    Date: Sun, 22 Aug 2004 00:43:21 GMT

    "panu" <panu@fcc.net> wrote in message
    news:4_KdnW2HSJXeSLrcRVn-pg@fcc.net...
    > Michael Feathers wrote:
    > > We can, but why isn't the test written so that the reason it fails is
    > > evident?
    >
    > That's a good question. Maybe the answer is
    > that there aren't any good guidelines for
    > writing unit-tests in a way that makes the
    > cause of every possible error self-evident.

    I don't know of any guidelines other than just writing code using TDD. I do
    know that when I use TDD, my code oftens ends up being less opaque that way.
    I suspect the key is that I end up exercising smaller chunks of code at a
    time.

    > How then, in general, do you write unit-tests
    > so that when they fail, the reason for their
    > failure is obvious, and "evident"?

    It's less about the tests than the code that is being tested. Here are some
    JUnit cases where reasons for failure are pretty evident when you look at
    the code being exercised. If something fails in tests like these, I can
    usually localize the error quickly by inspection. If I can't, I can narrow
    it down with another assertion or two. And, that's the key point: If
    something's wrong, is it easy to write a test case that tells you more? If
    it isn't, why not? Frankly, I'm jealous of you all in the Smalltalk
    community. You don't have to extract interfaces all over the place to run
    little chunks of code at a time.

    public void testCreateWithDefault() throws Exception {
      String className = "ghostworld.testing.ClassWithDefault";
      Ghostworld world = worldWithClass(ClassWithDefault.class);
      assertNotNull(world.makeObject(className));
     }

     public void testCreateWithSingle() throws Exception {
      String className = "ghostworld.testing.ClassWithSingle";
      Ghostworld world = worldWithClass(ClassWithSingle.class);
      assertEquals(className, world.makeObject(className).getClass().getName());
     }

     public void testCreateWithSinglePrimitive() throws Exception {
      String className = "ghostworld.testing.ClassWithSinglePrimitive";
      Ghostworld world = worldWithClass(ClassWithSinglePrimitive.class);
      assertEquals(className, world.makeObject(className).getClass().getName());
      assertEquals(0,
    ((ClassWithSinglePrimitive)world.makeObject(className)).value);
     }

     public void testNontermination() throws Exception {
      Ghostworld world = worldWithClass(ClassWithoutTermination.class);
      try {
       world.makeObject("ClassWithoutTermination");
       fail("should've thrown");
      } catch (Exception e) {
      }
     } 

    --
Michael Feathers
author, Working Effectively with Legacy Code (Prentice Hall 2005)
www.objectmentor.com
  • Next message: Richard Riehle: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"

    Relevant Pages

    • Re: Need function to test if EFFECTIVE UID has read-access to a file.
      ... and another reason why I can't use the method suggested by you is ... that I'm dealing with directories, ... kind of exception is.listdirthrows if it fails to read a directory? ...
      (comp.lang.python)
    • Re: Threading and Serial port issue
      ... "fails" is pretty useless information. ... If it generates an exception, ... I then sit in a loop waiting for data to arrive. ... private void SetupBoard_Click ...
      (microsoft.public.dotnet.framework.compactframework)
    • Re: Strange error when app starts
      ... installed correctly via the installer ... machines and until recently they all worked perfectly. ... updated the application to a new version one of the machines fails ... unhandled exception when the application starts. ...
      (microsoft.public.dotnet.framework.windowsforms)
    • Re: I need help please!
      ... It is documented on some systems I've use a lot as a standard way of exiting at any point. ... Any software written for general consumption should deal with unexpected keystrokes for the simple reason that, in the real world, they are very common. ... So you "REASONABLE man's method" fails on a very common system, ... I would say that a "solution" that does not work on a very common platform is NOT a reasonable solution. ...
      (comp.lang.c)
    • Re: Defensive Programming - Where do you Draw the Line?
      ... try/catch or try/catch/finally blocks. ... well-written exception code, try-finally is far more common than try-catch. ... exception is incredibly unlikely to occur, is there any good reason to ... It should be the other way round - if your method fails to execute, ...
      (microsoft.public.dotnet.languages.csharp)