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

RE: [XP] Re: Ship It

Expand Messages
  • Stell Smith, Jeremy (Thoughtworks)
    ... so we ve actually been working on a swing based gui testing tool. It s open source and loosely based on a couple tools I ve written for previous projects.
    Message 1 of 82 , Sep 1, 2002
    • 0 Attachment
      > I understand the concept, of course. I even understand my own
      > needs and
      > have a tool that sorta-kinda meets those needs.
      > Your point and Ron's was that the requirements of a testing
      > tool for the
      > particular person who posted the question wasn't known
      > because he hadn't
      > outlined any tests.
      > I then asked that the original poster outline some tests. It
      > seemed simple
      > to me.

      so we've actually been working on a swing based gui testing tool. It's open
      source and loosely based on a couple tools I've written for previous
      projects. It's called Marathon and you can find it at
      http://marathonman.sourceforge.net/ It's pretty sweet. It records and
      plays xml scripts that look something like :

      <test>
      <window title='Sample Dialog'>
      <click name='Press Me'/>
      <assert name='Press Me' text='Press Me'/>

      <click name='Show Message Dialog'/>
      <window title='Message Dialog'>
      <click name='OK'/>
      </window>

      <select name='textField' text='abc'/>
      <select name='comboBox' text='foo'/>
      <assert name='comboBox' text='foo'/>

      <select name='comboBox' text='bar'/>
      <assert name='comboBox' text='bar'/>

      <select name='comboBox' text='baz'/>
      </window>
      </test>

      The goal is to end up with scripts that are as simple and readable as
      possible, because that makes them as maintainable and writeable as possible.
      We liked the idea of a recording tool for QA, but we needed the scripts to
      be part of the code, we needed developers to be able to maintain them, and
      we needed them not to brake every time something silly changed.

      It's good fun, I've been working on this with some brilliant guys. We're
      doing it 100% test first, and as much XP as we can figure out how to work
      into an opensource project. We've been releasing every week or two for a
      bit, so it's been really good to see it evolve. Our stories are at
      http://wiki.truemesh.com/marathon/StoryQueue

      The next step for Marathon is getting an actual customer. (I'm a poor
      excuse for one) So if anyone - especially the original poster is
      interested, I'd love for you to take a look. It's very stable, and has (I
      believe) enough functionality to be of immediate use on a project. The
      bonus is that you get to tailor it to what you need.

      BTW, we DID look at buying other tools on my previous projects. In fact, we
      actually had rational robot. It didn't meet our needs. We wanted it to do
      things that it couldn't do, and tests weren't getting run. I can go into
      more detail if people want. The beauty of an inhouse/open source solution,
      is that there's a lot fewer hoops to go through to get it to do what you
      want. You want it to do X - make it do X.
    • 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.