Consider reducing the number of specs

This may look like a weird request, and it probably is, but have you considered reducing the number of *Spec classes? This will allow the library to be more opinionated in how the tests should be written, which is good IMO.

For instance, StringSpec and FunSpec are almost the same, modulo an extra test call. I think using String.invoke to define tests is a clever hack, but wrapping the string in test is just an concise and much less surprising for the user.

Similar reasoning applies to ShouldSpec. Are the cases defined with should any different from the ones defined with test? Maybe. But is it worth the extra concept in the library?

What do you think?

[sksamuel]

@superbobry agreed, early deprecation is best. I think in this case though we don’t know if we even want to deprecate yet. Some people are saying have one spec, others (like me) are saying leave it alone as it works and everyone seems to like a different spec.

For me, @helmbold’s last comment is the best approach.

[helmbold]

I tend to leave it as is, too. I think it would be fine to use StringSpec for all examples and still offer the other styles. If we learn that some specs are rarely used, we could deprecate them later.