Organize test suite to use Spectrum to test Spectrum

[greghaskins]

Spectrum was originally bootstrapped by test-driving with traditional JUnit tests. Most of those tests live on in packages like given.a.spec.with.nested.describe.blocks. Later on, Spectrum became feature-rich enough to be able to test itself (dogfood), for example FixturesSpec and of course ExampleSpec).

This mix of testing styles makes it hard to figure out what is tested where and how. It should be possible to convert all the old vanilla JUnit tests over to Spectrum, but if not, that exercise may reveal important functionality gaps.

I've been trying to follow these rough guidelines:

1. Prefer testing "happy path" Spectrum behavior with direct examples (similar to the Jasmine docs). Just call the functions in the appropriate context and assert that they behave correctly.
2. Avoid having "expected" failures or ignored specs in Spectrum's test suite. Test those "sad path" behaviors through indirection with SpectrumRunner instead. For an example, see RunnerSpec
3. Try to organize suite files around functional boundaries (e.g. a suite about focused specs in one file, another about ignored specs, etc.)
4. When adding features, always include an example in ExampleSpec and update the README. Test all the edge cases in the suite itself, but it's good to have an overview that is big and visible.