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

[XP] Re: Ship It

Expand Messages
  • jhrothjr
    ... It has attracted an answer. At least, I ve seen answers several times - on the newsgroup. Robert Martin s answer is to write your own tool for each
    Message 1 of 82 , Sep 1, 2002
    • 0 Attachment
      --- In extremeprogramming@y..., Steve Willer <willer@n...> wrote:
      > > [egb> ] you have to make an intelligent extrapolation. If you wait to
      > > tool until you have all the tests, then you end up with an "all tests
      > > up front" situation, which is not good. If you take tiny steps to
      > > manage your tests, there may come a time that you determine those
      > > solutions to be fragile and unable to not scale. We see this with
      > > testing tools, change management tools, version control tools...the
      > > whole spectrum. Changing tooling in the middle of a project is
      > > disruptive, and trying to build your own is often a false economy.
      >
      > Neat. This thread is like 99% philosophy and 1% concrete examples, tests
      > or requirements. Does that mean a 1% signal/noise ratio? ;-)
      > Perhaps the guy who was asking about what "pure GUI" testing tool everyone
      > uses could just throw out three to five example tests that he is thinking
      > he'll run. Then somebody else who does those kinds of tests can put up
      > their hand and say "Ooh! I use WinRunner, [and I love it | but I hate
      > it]", or whatever.
      > That way we can have some tests and also some idea of tools. Because I've
      > certainly wondered for years how exactly people automate acceptance tests
      > typically. And I know it's been asked a million times but the question
      > never seems to attract an answer.

      It has attracted an answer. At least, I've seen answers several times - on the newsgroup.

      Robert Martin's answer is to write your own tool for each project. His reasoning (which I like) is that the acceptance tests are part of the conversation between the customer and the development team, so they should be just as readable to the customer as the developers. That's very unlikely to be true for a COTS product, or for xUnit, for that matter.

      An example someone gave was a customer who was an actuary. This guy presented his tests in a spreadsheet. The developers simply used the spreadsheet API to drive the application and check the resulting numbers.

      A general theme is that GUI acceptance tests can't be automated because they're visual, and while there are tools, they are expensive, fragile and developer time sinks. The recommendation is to use a very thin client, and put all the testable logic in a class that can be accessed by a batch program.

      I would think that the same reasoning might apply to the recent example of a report. If the problem with the printer was that it couldn't do something like a particular color, or slice pages apart from roll paper, or whatever, then it's going to be real difficult to write a test for that. I _could_ think of something, but I'd rather not.

      John Roth
    • stewartbaird
      Hi Bryan I agree with your comments about the sociology aspects of software development - Peopleware made that point 15 years ago. Also, I hold to the view
      Message 82 of 82 , Sep 30, 2002
      • 0 Attachment
        Hi Bryan

        I agree with your comments about the sociology aspects of software
        development - Peopleware made that point 15 years ago. Also, I hold
        to the view that software development is more ART and than science.
        As a wanna-be artist, I throw away most of what I paint on the way to
        my next masterpiece. (Ok, I don't *actually* throw it away- I file it
        in a drawer).

        The empirical nature of design is where XP shines for me. Its fun
        too, watching users create their own solutions. We just take notes
        in the form of code.

        sb

        --- In extremeprogramming@y..., "Bryan Dollery" <Bryan.Dollery@C...>
        wrote:
        > Hi,
        >
        > Grady followed nicer posting practices, and wrote:
        > > > We have to - everything that existed before XP contributed to
        > > the crisis,
        > > > and the high failure rates (variously quoted as between 50% and
        70%).
        > >
        > > [egb> ] oh my; you are in effect saying that all that preceded
        > > XP is bad and
        > > evil; all that follows XP is well and good. I do embrace XP - but
        at the
        > > same time do not find it necessary to reject all that came before it.
        >
        > This is why we call it Extreme
        >
        > :-)
        >
        > It did come across a bit strong, but I do believe that there is some
        truth
        > in it.
        >
        > Of course, I may have not made the context too obvious. I meant
        everything
        > *in the software process domain*. So, I wasn't saying that the
        concepts of
        > modularisation are bad, just the order in which people tend to apply
        them,
        > and the focus they give them. Similarly testing tools, not bad as
        such, but
        > used badly (and in some cases based upon bad ideas - gui recording
        tools,
        > yeuch).
        >
        > > > Also, each project is unique, why would you want to constrain
        > > a project's
        > > > optimal evolutionary path by constraining some part of it a priori?
        > >
        > > [egb> ] But there are pragmatic constraints. Shall I eliminate the
        > > artificial constraint of the set of programming languages that I
        > > may choose
        > > from, and instead write my own language first? The existing ones
        are so
        > > confining... What about operating systems? Shall I write my own so
        as to
        > > permit my project to follow its optimal evolutionary path?
        >
        > Military
        > Space Exploration
        > Telecommunications
        >
        > Isn't that almost exactly what happened in these domains up until
        recently?
        >
        > US Mil: Current languages are crap, lets build our own, and call it ADA
        > Grady: Oh, that means I'll have to teach you all how to program in it
        > efficiently
        >
        > So, it's been done before - that's where most of the current OSs and
        > languages came from.
        >
        > Does reusing an existing platform increase your productivity - yeah, but
        > the cost seems to be 50%-70% of project failure - which would mean 0%
        > productivity. You have a tradeoff, as you mention below, between
        cost and
        > risk.
        >
        > The point is, if you don't want to repeat the mistakes of the past, you
        > have to start by not repeating the past.
        >
        > > [egb> ] Starting with a completely blank page is typically worse than
        > > staring with a page for which you at least know where the edges lie.
        > > Ultimately, software development is an engineering problem,
        wherein one
        > > finds a balance among the forces upon the project.
        >
        > I disagree - software development is a sociology problem, about how
        to get
        > people to do engineering effectively. There is clear evidence for this -
        > Jones points out that project success or failure rarely, if ever,
        depends
        > on technology. I know that Jones' data may not be a representative
        sample,
        > but it's the best we have at the moment, and it's indications are
        clear -
        > software development is sociology.
        >
        > Writing good code is an engineering problem. Getting people to do this
        > efficiently is a sociology problem. Putting in place the funding and
        > facilities to write code is an business problem. Discovering the
        > fundamental rules and techniques that the programmers base their
        > engineering discipline on is an academic task. Ensuring that there is a
        > national (and to some extents global) economy that supports that
        business
        > is an economic and governmental problem.
        >
        > My point, to reiterate, is that just because engineering is involved
        > somewhere in the mix doesn't make this an engineering problem. You can't
        > engineer societies, and this seems to be the major mistake that
        people have
        > made that has led to the software crisis and our abysmal success rate.
        >
        > Cheers,
        >
        > Bryan
      Your message has been successfully submitted and would be delivered to recipients shortly.