Refactoring: Benchmarking: Ensure it runs faster than before the refactoring

[eduncan911]

This is already done; but, a note here is required.

I've executed close to 700 specs in under 1.8s using mspec as-is today. That is not slow - in terms of all other BDD test runners I've used in the past (Java, C#, NodeJS, Ruby, Python, etc).

But, it is slow in regards to Go! Especially when compared to raw unit testing of Go.

To prove this, I've added a number of benchmarks already to compare mspec to normal Go tests. The results are:

BenchmarkGivenStub-8     1000000              1280 ns/op
BenchmarkWhenStub-8      1000000              1334 ns/op
BenchmarkThenStub-8      1000000              1464 ns/op
BenchmarkError-8           50000             38173 ns/op
BenchmarkSimpleMspec-8   1000000              1850 ns/op
BenchmarkSimpleTest-8   200000000                8.11 ns/op
BenchmarkComplexMspec-8   500000              3832 ns/op
BenchmarkComplexTest-8  30000000                42.9 ns/op

Focus on the last 4. You can see that mspec as it stands today is about 220x slower on simple tests, and about 90x slower on more complex unit tests written in raw Go tests.

That's not too bad, considering you still can run a 1000 specs in under 2 seconds. Also, remember you can make Go even faster by specifying which test to run like go test -run Test_Registration. But it's fast enough.

These benchmarks were written to set a baseline before the refactoring. That way, during refactoring to using channels and goroutines, we can see if there are any regressions.

I predict a number of regressions (since we'll be adding a lot more objects for the GC, more context, and optional runners) for simple tests. But, if creating complex specs with multiple Whens and multiple Thens, it should be a significant speed up with the built-in channels we'll have.

See #4 for more details.