Add Unit Tests

[jasonLaster]

It'd be great to get some test coverage over the debugger. From my experience, this makes it easier to add new functionality without introducing regressions. Also, a lot of the backboneAgent logic is difficult to manually reproduce and a test environment makes the feedback loop much tighter.

The Marionette Inspector has two test hanesses, one for the agent and the other for the inspector panel. We did this to separate out the two flows. I'm considering splitting up the inspector test suite into smaller functional bits, but thats another story. Here's the two test bootstrap files:

Harnesses

• agent
• inspector

Agent harness

With the Agent, the big challenge is to reproduce injecting the script into the window for each test execution. We achieve this by building a small core script that does not include any of the startup logic and then for each run, we reset the main agent state, reload backbone, and re-patch backbone... This is pretty hard to get right and you'll see that a lot of duck tape is used.

The end result though is great, as we've got tests on lots of utilities and the serializing logic.

Inspector Harness

With the panel, the big challenge is to build a sandbox environment that the inspector feels comfortable living in. For the most part, that's just stubbing out the chrome apis and getting the require.js configuration to play nicely. You'll notice that this requires starting up a local server and managing the initial chrome page connection.

The recorder / sandbox environment FTW

So, once these two test environmnets are setup you can do a lot to automate some of the coverage, but that's really for computers and doesn't do too much for humans. Enter the recorder. The recorder records messages tha the panel receives from the agent. The sandbox starts the inspector on it's own page (outside of devtools) and plays back the messages from the agent. The result, is a magical world where the inspector can be started by itself. This is great for UI work, new feature development, and is wonderful for humans who want to get shit done. sandbox.

These three things are better outlined in the
getting started guide

[Maluen]

@jasonLaster Thanks for taking the time to open the issue, plenty of useful information that will help throughout all the testing environment creation process.

Obviously the process needs to by achieved step by step, the most important thing for now is being able to run the agent in a separate environment, backboneAgent doesn't have any startup logic in it, so we should be able to have an external loadable agent file by just concatenating the scripts stated in the index.json file, e.g. by using grunt.

Then we can create an html file like yours AgentSpecRunner.html and load the created agent file there.

I'm not an expert on testing, but when you say

and then for each run, we reset the main agent state, reload backbone, and re-patch backbone... This is pretty hard to get right and you'll see that a lot of duck tape is used.

Wouldn't be possible to use a method where you reload the index.html altogether and pass to it the name of the test you want to run, for example by GET parameters.

This assuming you can organize in your tests as small javascript applications / files that the spec runner will load, based on the received name and other parameters. You would have a fresh new new state probably with only some initial effort to setup the system.

Or there are reasons for needing a single-execution, like reusing states, etc?

[jasonLaster]

Hmm. So on the phone, but will try to give as much info as possible.

• yup grunt and run. Mocha/jasmine chops do 80%
• take a look at agentSpec.js for what I do with state
• an iframe for each test makes sense. In some ways much better. JasmineIntegration does this. It makes step one of every test load iframe, and it's slow, but it works.