J3Unit and Floyd

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

J3Unit and Floyd

R-24
Has anyone looked at these two projects? How do they compare or differentiate from Selenium?

J3Unit: http://j3unit.sourceforge.net
Floyd: https://floyd.dev.java.net/
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.openqa.org/thread.jspa?threadID=993&messageID=2761#2761

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: J3Unit and Floyd

Dan Fabulich
Patrick wrote:

> Has anyone looked at these two projects? How do they compare or
> differentiate from Selenium?
>
> J3Unit: http://j3unit.sourceforge.net
> Floyd: https://floyd.dev.java.net/

Is there more to Floyd than the blurb on that page?  I don't see any code
to download, documentation, etc.?  Hard to say more without more
information.

As for J3Unit...  it pretty much describes its purpose on the home page: a
combination of JSUnit with the Script.aculo.us Test.Unit.Runner.  It's
aimed at being JSUnit (a developer-centric unit testing framework for
JavaScript) but with the added features of the Script.aculo.us runner.

JSUnit has a bunch of handy runner tools to launch browsers on multiple
machines and collate their results, but not much of use when it comes to
testing anything asynchronous (which is practically everything in JS).
Script.aculo.us has a nice asynchronous JavaScript test runner, but lacks
the infrastructure available in JSUnit.  Two great tastes should taste
great together.

One thing that's interesting about the Script.aculo.us runner that I
didn't know is that they have a very novel pure-JavaScript "wait" function
that's somewhat suitable for use in a unit test.

http://dev.rubyonrails.org/browser/spinoffs/scriptaculous/src/unittest.js
http://dev.rubyonrails.org/browser/spinoffs/scriptaculous/test/unit/ajax_autocompleter_test.html
http://tinyurl.com/74sgs

The test looks like this:

testAjaxAutocompleter: function() { with(this) {
  // blah blah blah initiate the AJAX Request
  wait(1000, function() { with (this) {
  // assert that the request worked
  // do some more stuff
  wait(1000, function() { with (this) {
  // assert some more stuff
  }});

  }});
}}

The code does stuff until it gets to the wait function, at which point it
returns, setting an "isWaiting" flag.  When the runner sees that the test
is waiting, it schedules that part of the function to run in 1000 ms. This
looks a little painful to write... in the linked test, which is pretty
simple, you find yourself in nested wait blocks going five layers deep;
imagine trying to do this with a more complicated functional test!

As this infinite-nesting structure makes apparent, you can't really wrap a
for loop or a try block around both stuff before and after the wait.
After any call to wait(), your test function needs to return right away.

Hence, you still can't write a test like this:

testWithConditionalLooping: function() { with (this) {
  for (var i = 0; i < 5; i++) {
  if (foo) {
  initiateRequest();
  verifyRequestWorked();
  }
  }
}

... but since this is a restriction of the JavaScript language itself,
it's a bit churlish for me to criticize them for this.  It's an admirable
workaround for a very challenging problem.

With that said, admirable though it is, I'm not sure if I have any use for
it.  Selenium Driven Mode (when it works) is a substantially more elegant
solution for developer-centric tests; since it's in a separate driving
process, it's able to sleep "normally" and use the full power of the
language to do its work.

And, as I understand it, that's why the Ruby on Rails team is trying to
switch to the Ruby Selenium Driver and off of their own crazy testing
framework for AJAX testing.  Driven mode is simply a better solution for
what they're doing... not a big surprise.

-Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]