[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [swtbot-dev] general question about how SWTBot works

Comments below.

  Mariot Chauvin

  +33 (0) 164865850
  Obeo Saclay
  2 Route de la Noue - BP76
  91193 Gif-Sur-Yvette

Le 13/04/2011 16:44, Tom Brus a écrit :
Indeed Mickael, that was the sort of setup I was imagining, although you take a shared disk or so as a prerequisite, while I was thinking of sockets on the network. A disk might do the trick though.... good idea.

I have to think this over in detail. I will inform the list when things get moving...

Anybody any remarks on Jubula? (or should I ask the jubula mailing list ;-))

My point of view, is that it's much easier to write and maintain tests with SWTBot than with Jubula.
The quality of the tooling for Java (Thanks to JDT) and the fluent API of SWTBot make that it's really easy to write a test.

However if your user/functionnal tester hate programming or hate having to deal with a textual langague, I understand they may prefer Jubula.


On Wed, Apr 13, 2011 at 16:37, Mickael Istria <mickael.istria@xxxxxxxxxxxxxx> wrote:
Ok, I understand this better ;)

Maybe a way to achieve that is to write 1 TestCase per user, and write in your test some synchronization points. You could use a file to write when a user performed a set of action, and other user tests will wait for the file to contain a specific token to go ahead.

For example
TestUser1() {
  // Do Step 1
  // Step 1 done
  // do Step 4

TestUser2() {
  // Do Step 2

TestUser3() {
  // Do Step 3

Then you can start one instance of your app for each user with a different TestCase, and the implementation of waitForStepDone ensure the sequence of actions is well performed.

However, I admit it is not so easy to maintain...

Please keep us informed if you make progress on this topic, that's something that could be useful for my product too ;)


Le 13/04/2011 16:23, Tom Brus a écrit :
Thanks for the pointer  Ketan, I will have a look, but our schedule will probably not allow us to maintain our own fork...

Brittle is indeed the word ;-) but then the main aspect of our application is multi user so we need to know if problems occur there before shipping.... alas.


On Wed, Apr 13, 2011 at 16:10, Ketan Padegaonkar <ketanpadegaonkar@xxxxxxxxx> wrote:
On Wed, Apr 13, 2011 at 6:26 AM, Tom Brus <tombrus@xxxxxxxxx> wrote:
> I am specially interested in these issues because our application needs
> multi user testing and I need to orchestrate parallel starts of our
> application on multiple machines. If every instance is running its own test
> in its VM it is just harder to synchronise.

Someone had forked SWTBot to add RMI support in order to do just this.
They were building some plugins for pair programming and needed to
orchestrate 2 eclipse instances from within one test.

The fork is available at: https://github.com/szuecs/swtbot. It is
slightly out of date, but you should be able to apply those patches to
current master.

From prior testing, this form of testing is very very brittle given
the number of moving parts. I'd suggest keeping it to a bare minimum.

- Ketan
studios.thoughtworks.com | twitter.com/ketanpkr

_______________________________________________ swtbot-dev mailing list


Mickael Istria
R&D Engineer

BonitaSoft - Open your processes
email : mickael.istria@xxxxxxxxxxxxxx

Best Eclipse Modeling Tool 2011

This message and any attachment (the "message") is intended solely for the addressees and is confidential. If you receive this message by mistake, please delete it and notify the sender immediately. Any use not in accordance with its purpose, any out-spread or disclosure, either as a whole or partially, is prohibited except with formal approval. Internet cannot guarantee the integrity of this message, therefore BonitaSoft will not be liable for the message if modified.

swtbot-dev mailing list

_______________________________________________ swtbot-dev mailing list swtbot-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/swtbot-dev

JPEG image