[TIP] Fwd: Robot Framework 2.0 is available!
stefano.masini at pragma2000.com
Wed Jun 25 01:44:03 PDT 2008
On Wed, Jun 25, 2008 at 9:51 AM, Laura Creighton <lac at openend.se> wrote:
> The usual rational for not using a language for acceptance testing
> is that your acceptance testing is to be done by managers and other
> people who are expected to turn bright purple and explode before
> they would ever write one line of python code.
Yes, of course, this is the usual argument.
In my experience though, this kind of acceptance test is more familiar
than writing python code just as far as the representation (table) is
concerned. But the kind of formalism required and the engineering
mentality that is needed in order to meaningfully write an *actual*
test is far from what can be achieved by a manager anyway.
Therefore if tests are to be written hand in hand with the customer,
some technical guy must be present in the meeting anyway. And, yes, a
tabular format may be more readable than python code to the customer's
eyes, I agree. But I think we're not talking about orders of
magnitude. In other words: if the customer's mentality is on another
planet, a table is no better than python code. If, on the other hand,
he's quite inclided to an engineering approach, a table might be
understood well enough, but maybe python code may be understandable as
well with just an extra little effort.
Or maybe not. I'll have to try. :)
> Something I am very curious about in this context is Resolver
> http://www.resolversystems.com/ (Hi Michael!) Through it a great
I'm using Resolver One for maintaining our backlog (term taken from
Scrum indicating an Agile practice, for those who don't know, where
all the work that has to be done yet is maintained in a spreadsheet
together with effort estimates, so that it is possible to calculate a
tentative schedule for short-term planning, far from reality, but
still very useful).
I think it's a great idea, even though the product is still rough on
the edges I think. I still find myself doing cut & paste to and from
excel in order to effectively play with the rows, since doing it
inside resolverone is very slow and sometimes it crashes. :(
By the way, thumbs up for Resolver Systems! :)
More information about the testing-in-python