- headless v. javascript driving browser v. full browser-level
- js-only v. test-specific html page v. load full app html
- local v. cloud
And the current contenders go something like:
- Selenium: browser, full app, local
- Sauce: browser, full app, cloud
- FuncUnit: js-browser, full app in iframe, local
- qUnit: js-browser, sparse html page, local
- JS Test Driver: js-browser, js-only, local
- ad infinitum...
The result is that you need (at least!) three different tools to do three different but required tasks:
- unit tests that run in a quick-feedback, autotest style on the command line
- module-level tests that require a small bit of DOM access and cross-browser testing
- integration tests that require loading the full app and triggering events on it.
It would be better if we could come up with a convenient, simple abstraction that allowed doing all three, and sharing code for mocks across the three, and configuring in what environment and what machine they each run.
Ideally, this could be done with AMD and wire.js. Just write a test in javascript, declare its dependencies, and they get injected.
- Unit tests depend on just one or two js files. They get loaded and then the tests run.
- Functional tests depend on "dom," provided either by a browser or a zombie.js-style headless dom, and a variety of js and html snippets. They all get loaded and run.
- Integration tests depend on "app", provided by actually running against one of your servers. It spins up, the tests run, maybe there is an API for telling the test server to reset itself to a known state between tests.