Hi,
Did anyone use http://code.google.com/p/js-test-driver/
Features
• Command Line Control: JavaScript code in the browser by design is
not allowed to interact with the filesystem or command line. This creates
problem when trying to run tests in an automated fashion. A good test runner
needs to allow control from the command line so that tests can be launched
from an automation script. This also implies that the tests need to be able
to publish their results to standard out or a file, outside of the browser
sandbox. The JavaScript takes care of controlling and marshaling test
results from the browser sandbox and make them available on the command line
interface (or Java API).
• Parallel Test Executions Across Browsers: JavaScript development
means write once and test everywhere. It is quite common when developing
that code passes in one browser but fails on others. If the developer is
testing with just one browser then the most likely outcome is that the code
works only in that browser. Checking the code into a continuous build than
runs the code in all browsers and results in failure which are hard to
debug, since the check-in can be quite large. JsTestDriver allows you to run
your tests in parallel on many browsers and platforms at once. This is
possible because the JsTestDriver server can capture any number of local or
remote browsers.
• Fast Tests Execution: TDD development asks to run tests often. Many
JavaScript tests runners require you to write an HTML wrapper file which you
refresh to re-run the tests, as a result you end up with lots of HTML
wrappers which are equivalent to test suites. This means that you can only
run one tests suite on one browser at a time. It also means that the browser
has to continually re-parse the production code as it executes the
individual tests suites. Finally running individual tests is often not
possible if the only control is browser refresh. We take a different
approach, JavaScript loads the production/test code at the beginning and
keeps them in the browser. It then reloads only the source files which have
changed. This greatly speeds up test execution, since in most cases the
browser only needs to re-parse a single file to re-run it.
• Full Control of DOM: Many JavaScript test harnesses report the test
results into the DOM. This means that portions of the DOM can not be
modified by the tests or you will lose the test result information. Since
JsTestDriver reports the test status on the command line, tests are free to
modify the DOM in any way they need for the test. JsTestDriver then resets
the state of the DOM for the next test.
• Easy Configuration: JsTestDriver comes bundled as a single JAR
file. There is no need to write HTML wrapper classes which have complex
script tags inclusions to bootstrap the test runner. All you have to write
is your source file, tests file, and a configuration file listing location
of your source/test files and you are ready to go.
• Code Coverage: CodeCoverage can be computed for your tests
• Declarative HTML Injection: Need specific DOM to be loaded to your
test executes, no problem: HtmlDoc
I wonder how Tellurium compares to this in terms of:
1. Command Line Execution of tests
2. Full Control of DOM
3. Running on multiple browsers
4. Possibility of integration with Continuous Integration tools like
Jenkins.
Thanks,
-Kamal.
--
You received this message because you are subscribed to the Google Groups
"tellurium-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/tellurium-users?hl=en.
