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

BTUF - Big Testing Up Front

Expand Messages
  • Thiago Arrais
    No, you don t need to read the title again, you are not mistaken. It really is a T instead of a D (or R, depending on where you come from). BTUF is the acronym
    Message 1 of 3 , Jan 1, 2007
    • 0 Attachment
      No, you don't need to read the title again, you are not mistaken. It really is
      a T instead of a D (or R, depending on where you come from). BTUF is the
      acronym for Big Testing Up Front. BTUF is basically what happens when
      people try to write all conceivable tests before starting to code. With the
      rise of Test-Driven Development this is an obviously ascending waterfall
      practice.

      Testing is also designing. When you write the tests before the production code
      in good TDD style, what you essentially do is design how the code will look from
      outside. Sometimes it may be hard to resist the temptation to design everything
      before writing a single line of code, specially for those used to
      waterfall thinking.
      For those who can't help doing it, here is some news from yesterday's paper: it
      doesn't work. Even though everybody minimally informed has already heard it,
      this message never gets said enough.

      It doesn't work because designing is infinitely better and easier when we can
      have fast feedback. Software development can be a high feedback bandwidth
      activity. Architects need to wait for the construction team to finish
      the piece and
      film writers sometimes need to wait years for the shooting to finish, but
      programmers can just compile their programs. Giving up this feedback on
      purpose is not the smartest thing to do. Writing all tests for a piece of code
      before starting the proper code is like drawing rectangles and arrows describing
      it in full detail before trying to make the whole think work. The
      over-engineering
      risk is the same because the code isn't there to scream in agony.

      The key to avoid BTUF is to write the tests that you can come up with before
      writing the code to make them green, but make sure _not_ to think too much.
      You can wait to start writing the code after all tests are in place,
      but you don't
      _need_ and neither _want_ to.

      TDD has shown us that design isn't made only of diagrams. In fact, we are
      designing all the time we are developing software. TDD is one of many
      design techniques: one that uses tests. It may be a better tool than arrows and
      rectangles in some situations. But is still just an approach for
      design. BTUF is,
      therefore, just an special case of BDUF where tests are used to determine the
      design completely before writing a single line of code.

      Cheers,

      Thiago Arrais
      --
      Mergulhando no Caos - http://thiagoarrais.wordpress.com
      Pensamentos, idéias e devaneios sobre desenvolvimento de software e
      tecnologia em geral
    • ken tyler
      My partner and I are trying to work through some of the things we re finding working for clients and I thought this group my be able to point us in some
      Message 2 of 3 , Jan 2, 2007
      • 0 Attachment
        My partner and I are trying to work through some of the things we're finding
        working for clients and I thought this group my be able to point us in some
        interesting directions. One thing we've noticed is that whenever we work
        with an organization on a project there are clear side effects, both on the
        people working with us and on other work inside the organization that
        overlaps the work of the project. Sometimes I've heard this referred to as
        "un-intended side effects". The "un" seems wrong, since one knows that the
        side effects will happen as a direct consequence of doing the work on the
        project.



        Naturally these side effects are very hard to predict, but they sometimes
        seem to be of great benefit (sometimes more than the original project). Does
        anyone know where we can look to find more on this area ? Has anyone ever
        tried testing whether on not certain side effects occur ? I have to go back
        and re-read Checkland and Weinberg as this seems to be systems theory
        stuff..



        Thanks



        [Non-text portions of this message have been removed]
      • Oleg Puzanov
        Great! Just to add: unit-tests for me is a piece of bravery before refactoring and some kind of intuitive programmist documentation. Cheers, Oleg Puzanov ...
        Message 3 of 3 , Jan 3, 2007
        • 0 Attachment
          Great!

          Just to add: unit-tests for me is a piece of bravery before refactoring and
          some kind of intuitive "programmist" documentation.

          Cheers,

          Oleg Puzanov

          On 1/2/07, Thiago Arrais <thiago.arrais@...> wrote:
          >
          > No, you don't need to read the title again, you are not mistaken. It
          > really is
          > a T instead of a D (or R, depending on where you come from). BTUF is the
          > acronym for Big Testing Up Front. BTUF is basically what happens when
          > people try to write all conceivable tests before starting to code. With
          > the
          > rise of Test-Driven Development this is an obviously ascending waterfall
          > practice.
          >
          > Testing is also designing. When you write the tests before the production
          > code
          > in good TDD style, what you essentially do is design how the code will
          > look from
          > outside. Sometimes it may be hard to resist the temptation to design
          > everything
          > before writing a single line of code, specially for those used to
          > waterfall thinking.
          > For those who can't help doing it, here is some news from yesterday's
          > paper: it
          > doesn't work. Even though everybody minimally informed has already heard
          > it,
          > this message never gets said enough.
          >
          > It doesn't work because designing is infinitely better and easier when we
          > can
          > have fast feedback. Software development can be a high feedback bandwidth
          > activity. Architects need to wait for the construction team to finish
          > the piece and
          > film writers sometimes need to wait years for the shooting to finish, but
          > programmers can just compile their programs. Giving up this feedback on
          > purpose is not the smartest thing to do. Writing all tests for a piece of
          > code
          > before starting the proper code is like drawing rectangles and arrows
          > describing
          > it in full detail before trying to make the whole think work. The
          > over-engineering
          > risk is the same because the code isn't there to scream in agony.
          >
          > The key to avoid BTUF is to write the tests that you can come up with
          > before
          > writing the code to make them green, but make sure _not_ to think too
          > much.
          > You can wait to start writing the code after all tests are in place,
          > but you don't
          > _need_ and neither _want_ to.
          >
          > TDD has shown us that design isn't made only of diagrams. In fact, we are
          > designing all the time we are developing software. TDD is one of many
          > design techniques: one that uses tests. It may be a better tool than
          > arrows and
          > rectangles in some situations. But is still just an approach for
          > design. BTUF is,
          > therefore, just an special case of BDUF where tests are used to determine
          > the
          > design completely before writing a single line of code.
          >
          > Cheers,
          >
          > Thiago Arrais
          > --
          > Mergulhando no Caos - http://thiagoarrais.wordpress.com
          > Pensamentos, idéias e devaneios sobre desenvolvimento de software e
          > tecnologia em geral
          >
          >


          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.