stdlib Spec framwork

[jkthorne]

The spec framework in Ruby has been changed to not have #should mixed into object. Here is a blog that mentions some reasons why it was changed. Should Crystal 1.0 be released with the Spec 1.0 style syntax?

[asterite]

Duplicate of #9029

In my opinion we could provide both syntaxes and then eventually deprecate should. But maybe it's a bit too late.

[asterite]

Also, that blog post is like 8 years old?

[kostya]

i not like that change, for me specs looks less readable, that why i still use rspec2

[asterite]

I think the expect syntax is great because it unifies marchers under a common syntax. For example we could introduce expect {...}.to change... by... and similar. With should it's not possible.

[jkthorne]

This might be an old topic but I feel like if it was going to change it should before 1.0

[straight-shoota]

I wouldn't be opposed to that, but there are other alternative proposals for an improved spec DSL (#8527, #3095). These discussions (including the precursors) have been going for years. But we couldn't manage to make a decision yet.

One of the reasons is surely that this is in part a very subjective topic (some people prefer syntax A others syntax B).
But other aspects also make this a really complex topic. For example different implementations have significantly different performance characteristics. And while we all want nicely looking specs, nobody would want have slower running specs.

In order to move forward in any direction, I think we'll need a detailed analysis of the options and their ramifications. Many of the original comments are old, things have changed. For example benchmarks could show different results than three years ago. We'll need a comprehensive writeup to fully embrace the alternatives and somehow make an informed decision.

If someone (or a group of people) is ready to conduct comprehensive research on this topic, I'm happy to support.

Whether that all could fit in the 1.0 timeframe is IMO questionable. But I also don't think it's particularly urgent. We can certainly introduce a new spec syntax after 1.0.

[jkthorne]

That all makes sense. I only brought it up because of the timeline but I can see now that it is probably too short to make any change to the 1.0 api. I am not the best person to write up that proposal I drastically prefer assert style test. The look more like code to me and I understand them better. So someone needs to write a full RFC?

[jhass]

Maybe we should decouple the matchers from the rest of the spec framework, which we could easily do. So require "spec" turns into require "spec" and require "spec/should". Then there could be spec-expect and spec-assert shards, we can watch if those proliferate and eventually include the most popular one into stdlib.

[kostya]

i think shard spectator already do this: https://github.com/icy-arctic-fox/spectator

[straight-shoota]

@jhass I don't see how that provides a reasonable benefit, especially considering the fragmentation is creates. Stdlib should ship with one spec framework/DSL and that should be the "best" for most typical use cases. If you want to have something different, that fits into a shard.

[jhass]

even RSpec ships the core example DSL and the matcher DSL in separate gems. The benefit is that you can reuse the example DSL and spec runner but don't need to pollute the namespace with (potentially conflicting) matcher APIs.