Skip to content

Commit

Permalink
docs: Outline the basic workflow.
Browse files Browse the repository at this point in the history
This short narative also helps introduce 'client' and 'context' terminology.
  • Loading branch information
johnjbarton committed Apr 13, 2018
1 parent d1effbf commit b5a2aa8
Showing 1 changed file with 22 additions and 1 deletion.
23 changes: 22 additions & 1 deletion docs/intro/03-how-it-works.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,28 @@ The server collects the results from all of the captured browsers and presents t

This is only a very brief overview, as the internals of how Karma works aren't entirely necessary when using Karma.

However, if you are interested in learning more, Karma itself originates from a university thesis, which goes into detail about the design
## Outline of workflow.

Here is roughly how Karma works:

After starting up, Karma loads plugings and the configuration file, then starts its local web server which listened for connections.
Any browser already watching the web address (localhost:9876 by default) will reconnect immediately. Karma also starts reporters
which register for 'browser' events.

Then karma launches zero, one, or more browsers, setting their start page the Karma server URL.

When the browsers connect, Karma serves a 'client.html' page; when this page runs in the browser it connects back to the server via websockets.

Once the server sees the websocket connection, it instructs the client -- over the websocket -- to execute tests. The client page opens an iframe with a 'context.html' page from the server. The server generates this context.html page using the configuration. This page includes the test framework adapter, the code to be tested, and the test code.

When the browser loads this context page, the onload event handler connect the context page to the client page via post-message. The framework adapter is in charge at this point: it runs the test, reporting errors or success by messaging through the client page.

Messages sent to the client page are forwarded through the websocket to the Karma server. The server re-dispatches these messages as 'browser' events. The reporters listening to 'browser' events get the data; they may print it, save it to files, or forward the data to another service.
Since the data is sent by the test framework adapter to the reporter, adapters and reporters almost always come in pairs, like karma-jasmine and karma-jasmine-reporter. The detailed content of test-result data is of no concern to other parts of karma: only the reporter needs to know it format.

Karma has many variations and options that may cause different workflow with different configurations.

If you are interested in learning more about the design, Karma itself originates from a university thesis, which goes into detail about the design
and implementation, and it is available to read [right here].

[right here]: https://github.com/karma-runner/karma/raw/master/thesis.pdf
Expand Down

0 comments on commit b5a2aa8

Please sign in to comment.