Dojo integration

[GoogleCodeExporter]

Just like the YUI JsTestDriver should be able to run Dojo tests.

Original issue reported on code.google.com by toc...@gmail.com on 11 Jun 2009 at 8:47

[GoogleCodeExporter]

Dropping back into the pool.

Original comment by corbinrs...@gmail.com on 13 Dec 2010 at 3:43

[GoogleCodeExporter]

How important is this to world? Speak up!

Original comment by corbinrs...@gmail.com on 5 Jan 2011 at 10:00

[GoogleCodeExporter]

Very :).

I like the way JsTestDriver is engineered, its DesignPrinciples (on the wiki) 
hit the spot, most specifically:
* Continuous integration support.
* Federated test executions.
make JsTestDriver _very_ powerful but I miss the following:

* DOM interaction.  JsTestDriver supports that, but it is rather simplified (I 
refer to the "Html in Tests") and feels indeed a bit complicated. I like the 
way dojo perceives a test as the whole package of HTML and JavaScript and CSS, 
which is a lot more flexible than what JSTestDriver currently supports. Dojo's 
test runner uses a similar technique as JSTestDriver:  the test is loaded into 
a different frame, in which it can totally mess up, it doesn't affect the test 
runner.
* Module dependencies are important.  CommonJS proves this and toolkits start 
to adopt it (think RequireJS).  Since dynamic code loading is part of a test in 
DOH, you also tests the correctness of a component's dependencies, something 
which you cannot guarantee if you always load the entire library.  Part of the 
strength of dojo (and YUI) is its capability to calculate the dependency tree 
on the fly  (or off-line if you make a custom dojo build).
* A personal note; we are not aiming to make an application, but rather a 
library/toolkit, based on dojo, which one can use to build applications.  Most 
of these components will be widgets, and will all interact with a pretty 
complex DOM.  We expect thousands of tests in the long run.  This would mean 
creating serveral JsTestDriver.conf files to keep the tests "managable" in the 
browser.  As an example:  try 
http://archive.dojotoolkit.org/nightly/dojotoolkit/util/doh/runner.html?testModu
le=dijit.tests.module
* I do not think that this is a feature that should be incorporated in 
JsTestDriver, but doh.robot (although I do not yet have experience with it) 
seems like a really valuable tool to automate UI interaction tests.  At least 
it has some documented benefits over frameworks like Selenium.  Additionally, 
it runs inside the browser, which makes it work in a federated test environment.

In conclusion.  dojo's test framework has its benefits.  On the other hand 
JsTestDriver has its benefits.  And I want them both :).  In the forum there 
was someone that uses dojo's build system to prepare the tests, unfortunately 
that source code is no longer available.  I rather thought in the lines of an 
adapter which allows you to plug in your own custom runner instead of making 
abstraction of only the Assertion framework.  The adapter would hence have to 
bridge the differences of a test definition and translate test results into 
something compliant with JsTestDriver.  This would allow you to plugin YUI Test 
(presumably, don't have experience with YUI) or DOH, while still benefiting 
from the heartbeat client, federated test environment, CI...  I'm not sure if 
this approach is feasible though, but that's why I'm writing this comment :)

Anyway, this has gotten way to long, but I hope it generates some discussion.

Original comment by Tom.Mah...@gmail.com on 21 Jan 2011 at 1:09

[GoogleCodeExporter]

I would very much like to see this also.

Note as you look at this, one thing to look at is that dojo allows you to 
change how files are loaded by using debugAtAllCosts:true. That changes it to 
loading using script injection, but then any code not loaded using a 
dojo.require needs to be wrapped in an dojo.addOnLoad (essentially I think 
testing harness would need to be wrapped in this). See the following for more 
info:
http://dojotoolkit.org/reference-guide/quickstart/debugging.html
http://dojotdg.zaffra.com/2008/12/how-debugatallcosts-works-or-a-quick-primer-on
-dojos-loaders/
http://kennethfranqueiro.com/2010/08/dojo-required-reading/

I'll add I personally would like to see JSTD use debugAtAllCosts so that stack 
traces give the correct line numbers.

d

Original comment by coolr...@gmail.com on 1 Feb 2011 at 3:04

[GoogleCodeExporter]

PS, There is an (old) thread on this in the dojo-interest group at 
https://groups.google.com/d/topic/dojo-interest/Xx5YWO4sBZA/discussion.

Original comment by coolr...@gmail.com on 1 Feb 2011 at 3:04

[GoogleCodeExporter]

I would very much like to see this also:)

Original comment by dariusz....@gmail.com on 15 Mar 2011 at 8:29

[GoogleCodeExporter]

Really, JSTD could benefit from allowing frameworks to load additional code in 
general. CommonJS Modules are becoming popular and are being brought into 
several frameworks including Dojo, jQuery/QUnit, and others...

Original comment by coolr...@gmail.com on 15 Mar 2011 at 1:09

[GoogleCodeExporter]

Yep, dojo includes CommonJS modules starting from dojo 1.6:  
http://www.sitepen.com/blog/2011/02/14/asynchronous-modules-come-to-dojo-1-6/

Original comment by Tom.Mah...@gmail.com on 15 Mar 2011 at 1:13

[GoogleCodeExporter]

I'm looking currently at how to automate dojo widget tests across browsers.  It 
would obviously be ideal to be able to merge the JSTD federation capabilities 
with DOH tools like the robot to be able to process not only high performing 
unit tests but also automated acceptance tests easily in parallel without 
resorting to other harness tools like selenium.   

Original comment by ryanmarshallmurray@gmail.com on 1 Apr 2011 at 2:51

[GoogleCodeExporter]

I agree, this would be a VERY nice addition

Original comment by warchild...@gmail.com on 12 Apr 2011 at 8:14

[GoogleCodeExporter]

Issue 219 has been merged into this issue.

Original comment by corbinrs...@gmail.com on 12 Apr 2011 at 8:30

[GoogleCodeExporter]

This is sort of a hack, but it seems to be working for me.
I'm using RequireJS as my loader and am loading AMD modules.
What I did was I told JSTD to only load a config file for RequireJS, RequireJS 
it's self and all my tests. Then in the serve section I list all of the AMD 
modules that should be loaded.

Then I created an AsyncTest and created a callback that will be called once my 
module is loaded.
require(['wire'], callbacks.add(function(wire) {...}));

Setting it up this way allows you to test all your AMD modules with out having 
to hard code the module name in the define().

One thing you have to do is add the --reset flag when you run your tests. This 
is because the loader is the one loading the javascript now so JSTD can't auto 
refresh it.

Take a look at my example project I've attached.

Raul

Original comment by ism...@ismell.org on 24 Jun 2011 at 5:08

Attachments:

• wire.zip

[GoogleCodeExporter]

I would also love to use dojo and JSTD together.

Original comment by Scott.Sh...@gmail.com on 25 Nov 2011 at 6:01

[GoogleCodeExporter]

I'll try Raul's method, but for the record, I am interested in this as well!

Original comment by jsh...@gmail.com on 19 Mar 2012 at 6:07

[GoogleCodeExporter]

Also, this goes much further than Dojo. I <3 Dojo, but RequireJS is a 
dependency management tool for big JS projects that can be leveraged with no 
other Dojo use at all, as I discuss in detail here: 
http://archmag.us/2012/03/16/care-and-feeding-of-large-javascript-projects/

Native JSTD support for JS src files that self-describe their dependencies via 
RequireJS would be most welcome.

Original comment by jsh...@gmail.com on 19 Mar 2012 at 6:10

[GoogleCodeExporter]

RequireJS is basically an AMD loader.  Dojo is since version 1.6 AMD compliant 
and can hence be loaded with any AMD loader (even more so in version 1.7).  
That includes RequireJS, but also other loaders.  The fact that AMD is becoming 
pretty widespread is an interesting development.

JSTestDriver is not AMD-ready last time I checked (admittedly, it's been a 
while ago).  JsTestDriver takes care of loading JavaScript code to the 
browsers, and it does that in its own (proprietary?) way.  I think this thread 
should no longer be about making JsTestDriver support dojo, it should be about 
making it AMD compatible.  Since dojo's test runner can be loaded as an AMD 
module, it's then still up to the programmer to use DOH or something else.

Original comment by Tom.Mah...@gmail.com on 22 Mar 2012 at 1:27

[GoogleCodeExporter]

I agree with Tom's assessment.

FTR, I have been able to use Raul's Wire project to set JSTestDriver up to 
support AMD loading, but it would be nice to have this integrated more directly 
into the JSTestDriver system and/or documentation.  The key is to realize that 
the JS files JSTestDriver serves under the 'serve' category are placed under 
"http://[server]:[port]/test" so your AMD loader needs to be configured to 
expect that.  In RequireJS's case, that means setting the baseURL field of a 
global require object before loading require.js.  It also means wrapping the 
JSTestDriver tests themselves within the AMD loader callbacks.

Original comment by jsh...@gmail.com on 22 Mar 2012 at 2:24

[GoogleCodeExporter]

Cool, I'm glad it worked for some one else :)

Original comment by ism...@ismell.org on 22 Mar 2012 at 2:42

[GoogleCodeExporter]

So, what exactly would constitute being AMD ready?

Original comment by corbinrs...@gmail.com on 22 Mar 2012 at 3:51

[GoogleCodeExporter]

Unfortunately it's not solely a case of supporting AMD.  I've got AMD working 
happily with Dojo and JSTestDriver, but getting DOH up and running is so far 
eluding me.  Yes, it would be extremely useful for JSTD to have native AMD 
support, but the bigger issues I'm finding are a) the lack of ability to launch 
arbitrary HTML pages (as opposed to pure JS), and b) the lack of support for 
HTTP HEAD requests with JSTD.

I think it's probably possible to run a pure headless DOH under JSTD, but it 
would be extremely useful to be able to run proper multi-browser UI tests using 
the DOH browser runner.  This makes huge use of HTML and iframes.  Systems like 
Yeti are happy to launch up HTML pages, but JSTD is very .js-focused. This 
harks back to commment #3 above with its discussion of the HTML-focused nature 
of DOH tests.

Similarly, the lack of HEAD support means that it's extremely hard to get the 
DOH Robot (a Java applet which supports low-level event pushing for UI 
automation) running.  I ended up hacking the DOH robot launching code, but the 
HTML issues above meant that I've still failed to get it going, even whilst 
able to run AMD.

So, yes, AMD is an issue, but there's more to it than that to get useful 
DOH/DOH Robot tests going.

Original comment by roys...@shufflebotham.org on 22 Mar 2012 at 5:53

[GoogleCodeExporter]

I very much need this too...

roys...@shufflebotham.org, are you saying that it's solely doh that's causing 
the problem? If so I could cope with that for now

Original comment by bod....@gmail.com on 30 Mar 2012 at 12:48

[GoogleCodeExporter]

It strikes me there are several sub issues to this particular one. I'd be much 
obliged if you could split them up, with specifics about the user facing 
portions of it. I'm afraid I don't have time to triage the expectations of the 
dojo testing framework, so as much information about how you would expect to 
write a test/config file as possible would be very useful.

Original comment by corbinrs...@gmail.com on 30 Mar 2012 at 2:50

[GoogleCodeExporter]

corbinrs:
The issues needs to be discussed between core committers from dojo and JSTD.The 
dojo loader requirements need to be explained, the problems (alongwith YUI) 
seem always to be caused by JSTD - because it needs to be the loader (and dojo 
has it's own loader)

DOJO DOH is just a unit testing framework (it can run tests on tests not using 
dojo), doh runner provides a gui for tests to report in.
The main issue seems to be the loader and the dependency that JSTD does the 
loading.
It seems like require/define needs to be in it's own local scope for dojo

I'd like you to contact the DTK, i'd also like to look through the JSTD java 
source to see if I could help. Where's best to start?

Code coverage is an excellent measuring tool and I wish JSTD worked with all 
libs because there's a distinct lack of mature JS code quality tools. The 
dynamic nature of JS means this is difficult but commonjs seems to be the way 
forward

Original comment by bod....@gmail.com on 10 May 2012 at 10:46

[GoogleCodeExporter]

Has there been any movement on this issue?  I would very much like to be able 
to use JSTD to test classes using Dojo and/or to run DOH tests.

Original comment by doe.matt...@gmail.com on 20 Oct 2012 at 3:47