Jason Cheatham

Another reason for this -- when directly importing interfaces, you'll end up building parts of intern into tests. That can lead to subtle issues.

I have an example project at https://github.com/jason0x43/intern-mocking-example that gives a couple basic examples using the `sinon` branch in intern. Both the branch and the example are still a work in...

@neonstalwart Just out of curiosity, what kinds of issues do stub behaviors cause with AMD?

Ah, that. I've been using intern's order module to [load all the pieces](https://github.com/theintern/intern/blob/sinon/sinon.js), which has worked well enough in my limited testing.

Just using `intern!order` didn't work so well after some slightly more complex tests, and I ran into the race condition mentioned by @neonstalwart. The most recent commit gets around that...

@neonstalwart It looks like 1.11.0 includes some improved AMD support (is there more in master?). I'll try it out. I was going for a stable interim solution since getting upstream...

Consider using [node-dependency-tree](https://github.com/dependents/node-dependency-tree) (or something similar) to build a mapping from test files to dependencies.

Using a port of 0 should autoselect an open port. The task in that case would be getting Intern to update the config with the port being used so that...

I totally agree!

This is also an issue with `browserStack`, at least with Intern 4.x. `{ "browserName": "safari", "browserVersion": "latest" }` gives an `OS/Browser combination invalid` error, whereas `{ "browserName": "safari", "version": "latest"...