Skip to content

Yeti Cocktails

Jump to bottom
reid edited this page Feb 17, 2012 · 5 revisions

Beginning with Yeti Sprint 4, Yeti will begin work on features that directly support Yahoo! Cocktails. This document details the points of integration that Yeti will support.

Yeti Sprint 4

Yeti Sprint 4 contains two tasks for Cocktails.

These tasks fulfill this story:

A user of Yeti would like to functionally test a set of Node.js HTTP server routes in a web browser. Yeti will provide a mechanism to run inside the HTTP server being tested. Yeti will accept a set of URLs to test aganist (instead of real HTML files) that will be served by the parent HTTP server. The parent HTTP server will serve the page with an embedded YUI Test that runs automatically and Yeti's inject.js. On the user's command, the Yeti Hub will instruct all browsers connected to it to navigate through the set of URLs and will collect test results from all of the browsers. The results will be provided as a JavaScript object, similar in schema to YUI Test's results object, through a basic Hub API for further processing in a Node.js application (e.g., mojito test).

Discussion

A basic API will be provided that can be used by another Node.js application, e.g. mojito test. This API will provide these features:

  • The ability to create a Yeti Hub.
  • The ability to mount the Hub onto another http.Server at a given mountpoint, i.e. "/yeti". Yeti will use this configuration in its inject.js.
  • The ability to create a Test Batch with a list of routes (relative URLs to the server) instead of a list of filenames.
  • The ability to listen for results in a YUI Test formatted JavaScript object from this API.

Using URLs with Yeti

Yeti will require you to include its inject.js script on the pages you're serving that contain YUI Test. You will also need to tell this script where Yeti is mounted on the server, say with a small script like $yetify({path:"/yeti"}).

Yeti's injection script uses the following globals that should not be modified:

  • io
  • $yetify

Getting test results from Yeti

You will provide the configuration and routes to Yeti by requireing Yeti into your testing CLI app. Yeti will emit an EventEmitter event when all test results arrive.

The supported flow would be to:

  • Run your CLI app, say mojito test.
  • Prompt the user to navigate browsers to the capture page URL, or use a Selenium or WebDriver library to open browsers to the capture page URL. These action fire Yeti's agentConnect events for your use.
  • Your CLI app would then dispatch the test when the user has connected the browsers they want.
  • Your CLI app would listen for Yeti's events to show test results as they come in.
  • Your CLI app would listen for Yeti's completion event to close the web browser and display a test result summary with the given test result object.

Caveats

Yeti Sprint 4's API is Unstable

Implementors should be aware that Yeti follows Semantic Versioning and these features are targeted for a 0.2.0 release. Therefore, the public API and integration points provided in this sprint will change in future Yeti sprints. We are working on this together and expect changes will be needed.

Yeti Sprint 4 will not handle certain common test errors

Yeti Sprint 4 will not address certain error conditions that can cause browsers to disconnect from the Yeti Hub. These conditions include but are not limited to:

  • A test or route given to Yeti does not exist.
  • A route served outside of Yeti does not contain inject.js with the proper mountpoint setting (you'll need to include a script that does something like $yetify({path:"/yeti"})).
  • A test or route given to Yeti modifies window.onerror.
  • A test or route given to Yeti contains an open <script> tag.

In these cases, Yeti may fail. For this sprint, implementors must take care that their tests are well-formed. Handling these kinds of errors is in Yeti's task backlog.

Yeti Sprint 4 uses all browsers

Yeti Sprint 4 does not let you pick which browsers to use. This feature is in Yeti's backlog.

Yeti Sprint 4 does not open browsers for you

Instead, use any number of Selenium or WebDriver client libraries to handle browser opening and closing to the Yeti capture page.

Yeti requires Node.js 0.6.x

Yeti requires Node.js >=0.6.0 <0.7.0 and is being developed against Node.js 0.6.10.

Yeti is not yet tested on non-Unix platforms

Read: Yeti is not yet tested on Windows, but we are interested in Windows support for the future.

Yeti Backlog

These tasks have been asked for by Cocktails, but they are not being promised for Sprint 4.

  • Configurable URL parameters for tests (i.e., appending ?coverage=1 or similar to all URLs or test files.)
  • Configurable timeouts.
  • Handling open script tags on test pages.
  • Handling window.onerror collisions on test pages.
  • Handling missing test pages.
  • JUnit output on Yeti's command-line interface.
  • Selectively using browsers, instead of all connected browsers.

Further Reading

This section and the linked articles are non-normative.

  • Yeti Next - background on Yeti Next, which is the basis of Sprint 4's work.
Clone this wiki locally