[EPIC] Improve unit test developer experience

[leggetter]

At the moment it seems like the process is as follows:

1. Start the test server using the CLI: ./bladerunner test-server
2. Connect one or more browsers via http://localhost:4224/capture
3. In another console/terminal tab run ./bladerunner test <test_location_to_scan>

In theory this doesn't seem to bad. However, based on my experience:

• Working out why a test fails is very difficult if the error occurs in js.bundle
• Running the tests sometimes gets stuck in a <browser_name>: reset slow cycle
• Running the tests sometimes results in the tests executing but the process not exiting
• Firefox sometimes hangs
• The server seems to take a long time to detect a browser has disconnected (30 seconds?)
• The debug experience is very difficult as the browser frequently doesn't actually know which line you are debugging (due to the size of js.bundle).
• CLI lists a Java exception when the JavaScript tests fail, which is confusing. It should just list the JavaScript test results and exceptions.

This is a very important part of the development workflow, so we make some improvements here.

[stevesouth]

Amy chance we can run headless?

-------- Original message --------
From: Phil Leggetter
Date:26/09/2013 19:06 (GMT+00:00)
To: BladeRunnerJS/brjs
Subject: [brjs] [EPIC] Improve unit test developer experience (#7)

At the moment it seems like the process is as follows:

1. Start the test server: ./bladerunner test-server
2. Connect one or more browsers via `http://localhost:4224/capture
3. In another tab run ./bladerunner test <test_location_to_scan>

In theory this doesn't seem to bad. However, based on my experience:

• Working out why a test fails is very difficult if the error occurs in js.bundle
• Running the tests sometimes gets stuck in a <browser_name>: reset slow cycle
• Running the tests sometimes results in the tests executing but the process not exiting
• Firefox sometimes hangs
• The server seems to take a long time to detect a browser has disconnected (30 seconds?)
• The debug experience is very difficult as the browser frequently doesn't actually know which line you are debugging (due to the size of js.bundle).

This is a very important part of the development workflow, so we make some improvements here.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7.

[leggetter]

👍 to running headless

[mikes-c]

And include support to generate code coverage

[fauna5]

In general we're going to be looking at other runners, so there may be little value in updating our current runner. We need to do some R&D here

[andy-berry-dev]

Closing this as it will be fixed by allowing configurable test runners (#8) and it's already possible to run headless using PhantomJS (we do it for the core BRJS library tests).