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

Re: [XP] automated testing makes the team go faster

Expand Messages
  • Edmund Schweppe
    ... Not necessarily true. Older versions of VB would quite happily let you run non-compiling code (and quite happily blow up if you tried to run the code in
    Message 1 of 29 , May 1, 2005
    • 0 Attachment
      Willem Bogaerts wrote:

      > Nope. A Visual Basic project will only run if all classes can be
      > compiled. That is why I see a non-compiling test as a missing piece
      > of code, not as a failing test.

      Not necessarily true. Older versions of VB would quite happily let you
      run non-compiling code (and quite happily blow up if you tried to run
      the code in question). VB.NET 2003 will tell you if build errors
      occurred - and give you the option to continue running your project.

      If you accept that option, you end up running whatever the most recent
      executable happens to be, which won't have the (non-compiling) changes
      built into it. I don't like accepting the option for that very reason.
      Still, it goes to show yet another advantage of going through the steps
      writing an expected-to-fail test, running the test suite and watching it
      fail prior to actually writing any code: if you *do* happen to end up
      running the old executable, the newly written test won't be part of the
      run and thus your expected red-bar won't occur. This will act as a clue
      that something didn't go the way you planned.
    • Adrian Howard
      ... [snip] ... I was poking at the abstract idea. Would it be different for you if you could write an explicit test (and is there really no way to test
      Message 2 of 29 , May 4, 2005
      • 0 Attachment
        On 1 May 2005, at 19:30, Willem Bogaerts wrote:
        > Adrian Howard schreef:
        [snip]
        >> Would it be different if there was an explicit test?
        >>
        >> For example In Perl I could test compilation of SomeModule by doing:
        >>
        >> use_ok( 'SomeModule' );
        >>
        >> Adrian
        >
        > Nope. A Visual Basic project will only run if all classes can be
        > compiled.

        I was poking at the abstract idea. Would it be different for you if you
        could write an explicit test (and is there really no way to test
        individual modules/classes in VB? To test one unit you have to compile
        everything! Scary.)

        > That is why I see a non-compiling test as a missing piece of
        > code, not as a failing test.

        Hmmmm... I think "failing test" and "missing piece of code" are pretty
        close to synonymous in my TDD brainwashed state.

        Adrian
      • Willem Bogaerts
        ... Well, that s just a language thing. I don t fight it. I could create another project with just that class, but I don t see much use in that. I work on my
        Message 3 of 29 , May 5, 2005
        • 0 Attachment
          Adrian Howard schreef:
          > On 1 May 2005, at 19:30, Willem Bogaerts wrote:
          >
          >>Adrian Howard schreef:
          >
          > [snip]
          >
          >>>Would it be different if there was an explicit test?
          >>>
          >>>For example In Perl I could test compilation of SomeModule by doing:
          >>>
          >>> use_ok( 'SomeModule' );
          >>>
          >>>Adrian
          >>
          >>Nope. A Visual Basic project will only run if all classes can be
          >>compiled.
          >
          >
          > I was poking at the abstract idea. Would it be different for you if you
          > could write an explicit test (and is there really no way to test
          > individual modules/classes in VB? To test one unit you have to compile
          > everything! Scary.)

          Well, that's just a language thing. I don't fight it. I could create
          another project with just that class, but I don't see much use in that.
          I work on my classes one at a time if I create them, so all classes
          compile with the possible exception of the one I'm working on.

          >> That is why I see a non-compiling test as a missing piece of
          >>code, not as a failing test.
          >
          >
          > Hmmmm... I think "failing test" and "missing piece of code" are pretty
          > close to synonymous in my TDD brainwashed state.
          >
          > Adrian

          But I think we drift off a bit here, I create my tests, along with the
          class and method signatures, in an UML program. In my own line of
          thought (self-brain-washing ? ;) ), I do test first, but I use a UML
          drawing program just before I code. The drawing program allows me to
          "sketch" the program structure and look at a larger scope. If, during
          implementation of the tests, I find out that a parameter is missing or
          that an instance of a helper class should not be passed but created in
          the class under test, I get back to the UML drawing program to have a
          good look at all the options on where to create a class or how to
          re-order the structure. I feel that, without the sketch phase, my scope
          is just too limited.
          Sometimes, like with a project I'm working on now, a class has too many
          tasks, but I only find out during implementation of it. So I need an
          extra implementation class. The sketch helps me tell me what classes
          should have access to it, when and where it should be created, what
          should be its life-span, etc.

          Maybe you come to the conclusion that it isn't pure TDD. Fine. Any way,
          I learned enough of the TDD experiences to let it influence my designs,
          tests and implementations.

          Let me give an example on how I work:
          [sketch] This class will process a data file an return an object tree
          [generated signatures and tests] the code compiles, nothing fails yet,
          as I haven't tested anything.
          I add the test class to the test schedule. I use my own Unit Testing
          Framework that does not use reflection, so I have the freedom to decide
          in what order the tests should be performed. The generated tests all
          fail with description "Test not implemented yet".
          [generated test] I implement them. They still fail, with descriptions of
          what really fails, and still compile.
          [generated signatures] I code the production code implementation. But
          wait! I need some object stack class during processing of the data file,
          really.
          [sketch] I sketch an object stack class.
          [generated signatures and tests] the code compiles. I add the test class
          for the object stack class to the test schedule, just before the
          processing class. As the object stack class does not depend on any other
          class and the processing class depends on the object stack class,
          naturally the object stack class should be tested first. The generated
          tests of the object stack all fail with description "Test not
          implemented yet".
          [generated signatures] I code the object stack implementation. The
          object stack code will pass at some point, and the processing class
          still doesn't. That is the moment I will incorporate the object stack
          into the processing class. Finally, all code will pass.

          Best regards,
          Willem Bogaerts
        • Adrian Howard
          On 5 May 2005, at 12:35, Willem Bogaerts wrote: [snip] ... [snip] I this works well for you more power to your elbow :-) That said process you describe doesn t
          Message 4 of 29 , May 6, 2005
          • 0 Attachment
            On 5 May 2005, at 12:35, Willem Bogaerts wrote:
            [snip]
            > But I think we drift off a bit here, I create my tests, along with the
            > class and method signatures, in an UML program. In my own line of
            > thought (self-brain-washing ? ;) ), I do test first, but I use a UML
            > drawing program just before I code. The drawing program allows me to
            > "sketch" the program structure and look at a larger scope. If, during
            > implementation of the tests, I find out that a parameter is missing or
            > that an instance of a helper class should not be passed but created in
            > the class under test, I get back to the UML drawing program to have a
            > good look at all the options on where to create a class or how to
            > re-order the structure. I feel that, without the sketch phase, my scope
            > is just too limited.
            > Sometimes, like with a project I'm working on now, a class has too many
            > tasks, but I only find out during implementation of it. So I need an
            > extra implementation class. The sketch helps me tell me what classes
            > should have access to it, when and where it should be created, what
            > should be its life-span, etc.
            >
            > Maybe you come to the conclusion that it isn't pure TDD. Fine. Any way,
            > I learned enough of the TDD experiences to let it influence my designs,
            > tests and implementations.
            [snip]

            I this works well for you more power to your elbow :-)

            That said process you describe doesn't bare a lot of relationship to
            the way I do TDD. Having an upfront sketch would I think, for me, get
            in the way of letting the tests tell me where the design should go.

            Cheers,

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