-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stdlib Spec framwork #10082
Comments
Duplicate of #9029 In my opinion we could provide both syntaxes and then eventually deprecate should. But maybe it's a bit too late. |
Also, that blog post is like 8 years old? |
i not like that change, for me specs looks less readable, that why i still use rspec2 |
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. |
This might be an old topic but I feel like if it was going to change it should before 1.0 |
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). 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. |
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? |
Maybe we should decouple the matchers from the rest of the spec framework, which we could easily do. So |
i think shard spectator already do this: https://github.com/icy-arctic-fox/spectator |
@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. |
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. |
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?The text was updated successfully, but these errors were encountered: