[TIP] Fwd: Robot Framework 2.0 is available!

[Pekka Laukkanen]

2008/6/25 Stefano Masini <stefano.masini at pragma2000.com>:
> Here's another reason I couldn't find it. It wasn't out yet! :)

Initial Google code project was created few weeks ago but we got
everything ready for the official release only yesterday.

> By the way, I gave it a try and it looks interesting. The way I see it...
[snip]

Thanks for kind words and a good analysis. Those of you who are
interested to learn more can check out the user guide at
http://code.google.com/p/robotframework/wiki/UserGuide or/and try the
framework hands-on.

> There's only one thing that makes me skeptical, but I guess that might
> depend on my inexperience with FIT or other acceptance testing
> solutions that work in tabular format: if all was made to resemble so
> much an imperative language, why not use the *real* imperative
> language? I mean, we're not talking about a syntactically complex
> language that's so overloaded to make it impossible to practically
> write acceptance tests beforehand (test first approach). We're talking
> about Python, that is, in my opinion, clean enough to be used almost
> as pseudo code in a planning session, to quickly hack together what's
> gonna become the actual test.
> But maybe, as I said, I'm just not experienced enough. Maybe I'll find
> that hacking together acceptance test tables is even easier. Maybe I
> will even be able to do this with the customer! (yeah... sure...) :)

My experience is that most customers or customer representatives are
not technical enough to understand any kind of real programming code.
That's why requirements are normally represented as textual use cases
or user stories, and one of the ideas about Robot Framework is that
requirements and test cases are exactly the same thing. The steps in
these test cases can be very high-level, for example "Administrator
logs into the system and there are no users in the database", and they
tend to read better in natural language especially if they have
punctuations or other special characters.

Test engineers can also be domain experts with limited programming
knowledge, and we've noticed that the simple tabular format provided
by Robot Framework often suites them better. Since lowest level
keywords map directly to methods in library modules or classes, it is
easy for more technical testers to start writing test libraries using
a real programming language.

One approach seldom, if ever, works everywhere and using regular
high-level programming languages for acceptance testing can be the
best solution in some contexts. One idea I have been thinking recently
is how to use both approaches in same project so that libraries can be
reused and results about all test cases combined.

Cheers,
     .peke