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

Re: [XP] Asynchronous versus synchronous continuous integration

Expand Messages
  • Gary Feldman
    ... Why do you say that? I recently deployed Emma (Java coverage) in our build file for one component, making it both fast and easy for developers to get
    Message 1 of 117 , Jan 1, 2005
    • 0 Attachment
      Robert Watkins wrote:

      > I would also posit that certain QA practices, such as determining test
      > coverage levels, take more time than a developer wants to spend, and don't
      > make much sense for a developer to run anyway.

      Why do you say that? I recently deployed Emma (Java coverage) in our build file for one component, making it both fast and easy for developers to get coverage data. It's trivial for the developers to run, and it creates a good target for them when doing after-the-fact unit testing. (This isn't an XP or TDD shop - yet.)

      In traditional development, most developers find it difficult to unit test their own code, or to know when their tests are good enough. It becomes frustrating for them because they're not used to thinking that way, and can't predict when they'll be done because they don't have a good definition of "done" for unit tests on existing code. Making it easy for developers to use coverage tools solves these problems, by giving them a much more concrete definition of being done. The developers are happier and the unit tests are likely better than they would have been had they been left to write them with no coverage tools.

      Gary
    • Chris Dollin
      ... I have learnt the hard way the following rule: never check significant modifications in (in our case, to SourceForge) ten minutes before going home time on
      Message 117 of 117 , Jan 18, 2005
      • 0 Attachment
        On Monday 17 January 2005 17:26, Jeff Grigg wrote:
        > > --- Robert Watkins wrote:
        > >> Personally, I find long builds offensive, _even if they
        > >> aren't causing me any pain_. The "Build Successful"
        > >> message is feedback, and I want to reduce the time that
        > >> feedback takes to arrive.
        >
        > --- Ron Jeffries <ronjeffries@X...> wrote:
        > > In what way are they offensive?
        >
        > Let's say it's Friday. At 5:23 P.M. I just checked in my changes
        > and I want to go home. But what if it takes Cruise Control 15
        > minutes to run all the tests? Should I wait until it completes,
        > confirming that my changes were good, before I leave for the
        > weekend? What if it takes half an hour? What if it takes an hour?

        I have learnt the hard way the following rule: never check significant
        modifications in (in our case, to SourceForge) ten minutes before
        going home time on a Friday, or indeed any other day of the week.
        Because, even if all the tests pass, even if you updated just recently,
        *that* will be when you forgot to cvs-add the new tiny class, and when
        the connection to SF is taking place along a stretch of salty string,
        and the fetch-code-into-paranoia-directory step takes forever, and
        *then* you discover there's a problem, and you've come in by train
        not car so an extra ten minutes isn't fatter traffic-jams and twenty
        minutes extra on the commute, it's getting home an *hour* later ...

        --
        Chris "electric hedgehog" Dollin
      Your message has been successfully submitted and would be delivered to recipients shortly.