Open GoogleCodeExporter opened 9 years ago
Dropping back into the pool.
Original comment by corbinrs...@gmail.com
on 13 Dec 2010 at 3:43
How important is this to world? Speak up!
Original comment by corbinrs...@gmail.com
on 5 Jan 2011 at 10:00
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
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
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
I would very much like to see this also:)
Original comment by dariusz....@gmail.com
on 15 Mar 2011 at 8:29
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
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
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
I agree, this would be a VERY nice addition
Original comment by warchild...@gmail.com
on 12 Apr 2011 at 8:14
Issue 219 has been merged into this issue.
Original comment by corbinrs...@gmail.com
on 12 Apr 2011 at 8:30
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:
I would also love to use dojo and JSTD together.
Original comment by Scott.Sh...@gmail.com
on 25 Nov 2011 at 6:01
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
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
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
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
Cool, I'm glad it worked for some one else :)
Original comment by ism...@ismell.org
on 22 Mar 2012 at 2:42
So, what exactly would constitute being AMD ready?
Original comment by corbinrs...@gmail.com
on 22 Mar 2012 at 3:51
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
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
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
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
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
Original issue reported on code.google.com by
toc...@gmail.com
on 11 Jun 2009 at 8:47