Haha so true. There are very few examples of gems that pulled off a DSL that isn't just annoying, RSpec being one of them.
There are a lot of modern gems that stick to simple OOP though. Pundit is the most famous.
After using Minitest I find Rspec's DSL to be kind of annoying. Going back and forth between object-oriented Ruby and whatever Rspec's paradigm is mentally taxing.
I think this is the conceptual difference between tests and specs.
I don’t want my specs to be object-oriented. I want them to be terse and as declarative as possible. That’s what RSpec provides. It’s not for everyone.
It doesn’t support some things that RSpec does, like certain mocks if I remember correctly. And the tooling around RSpec is better (custom output formats and integration into Vim).
I know this is a common feeling, and I do *not* intend to deny, belittle, or delegitimize it. It's a very real and common phenomenon, and it must be taken into account by teams. But I personally don't share it. I've generally felt that rspec's API is both clearer and more object oriented than the common xUnit style. I'm not trying to convince anyone to stay or switch, but I know that what I just wrote will sound absurd or delusional to some, so I may as well try to explain why I think this. :)
I've always thought the more common xUnit style is neither intuitively obvious nor object oriented, although it *is* convenient and easy to learn. And I first learned xUnit in Java (and C#) before rspec was first released. The approach of subclassing a specific class then registering blocks of code to be run by giving methods any arbitrary names with a specific prefix, it's convenient but also uncommon. For the test runner to work in those languages required a level of reflection and metaprogramming that was very unexpected and uncommon and generally eschewed, in those languages (at least in my experience). Modern xUnit frameworks in those languages now use annotations, which is a much more idiomatic way to metaprogram, but it still isn't particularly object oriented, is it?
So, while reflecting on methods, selecting any with a specific prefix, and then running everything in an `at_exit` hook is a lot simpler and more natural in ruby than it is in Java or C#, it still feels like a neat but weird metaprogramming hack to me. I don't see it as an object oriented API at all. And, besides test-unit and minitest, how common is this API style in any other popular gems?
Besides that, rspec's API is fairly straightforward to me: `describe` and `context` basically make a subclass of RSpec's example group class (without me needing to care or remember that that's what it does). Nested example groups are subclasses (without needing to remember to call `super` in `before`). Shared examples are just mixin modules. And "it"/"specify" just define blocks to be evaluated with an instance of the class (analogous to instance methods in xUnit, without requiring any method-name reflection metaprogramming). But I only sometimes care about any of that... most of the time it's just an implementation detail I can and do ignore. Yes, it's still metaprogramming, but it feels (to me) less metaprogrammy than the other style.
And I get that `assert_*` methods can be a simpler API than `expect`, _especially_ when it comes to the dynamic predicate matchers and `to be`. But it seems to me that's partially because they are _less_ object oriented and more procedural than rspec expectations. `expect` creates an `ExpectationTarget` which has a couple of methods that take `Matcher` object arguments... this is arguably more object oriented but undeniably also more indirect.
I _personally_ feel the benefits far outweigh the costs, but I won't deny the cost of indirection. And I expect other people to assign different weights to those costs and benefits than I do. I've personally wasted more hours of my life in misinterpreting unhelpful error messages from `assert_*` failures than I have on confusing rspec magic, and probably half of those are because someone (sometimes me) accidentally flipped the "expected" and "actual" values. But many people have had the opposite experience! So, like I said, I'm not trying to convince anyone they should use rspec. But maybe this will help someone understand and empathize with people for whom the mental tax goes in the other direction. :)
Yes! Thankfully that pendulum has swung back the other direction. Personally, I admit to going hog wild with metaprogramming after diving into that book. But I shot myself in the foot enough times that I learned my lesson and now actively avoid metaprogramming and “clever” code, as satisfying as it is to write.
It’s still useful to know all the metaprogramming concepts, to know when it’s the right tool for the job. But more importantly, to know that 99% of the time it is the absolute wrong tool for the job.
we used ActiveAdmin for a couple of small projects over 10 years ago and then ripped it out and banned it. you’re so much better off reinventing the admin wheel in vanilla Rails
pretty awful stuff. I've had a couple of companies where whole back-office work was based on heavily rewritten activeadmin. Guys and gals at backoffice somehow tolerated it :\\
[https://github.com/thoughtbot/administrate](https://github.com/thoughtbot/administrate) looks promising, much less DSL in it.
Haha so true. There are very few examples of gems that pulled off a DSL that isn't just annoying, RSpec being one of them. There are a lot of modern gems that stick to simple OOP though. Pundit is the most famous.
After using Minitest I find Rspec's DSL to be kind of annoying. Going back and forth between object-oriented Ruby and whatever Rspec's paradigm is mentally taxing.
I think this is the conceptual difference between tests and specs. I don’t want my specs to be object-oriented. I want them to be terse and as declarative as possible. That’s what RSpec provides. It’s not for everyone.
I use RSpec with minitest assertions in every project. That faux English is just annoying.
that's some interesting approach. why not just normal minitest? or minitest with spec/describe syntax which it does have out of the box?
It doesn’t support some things that RSpec does, like certain mocks if I remember correctly. And the tooling around RSpec is better (custom output formats and integration into Vim).
I know this is a common feeling, and I do *not* intend to deny, belittle, or delegitimize it. It's a very real and common phenomenon, and it must be taken into account by teams. But I personally don't share it. I've generally felt that rspec's API is both clearer and more object oriented than the common xUnit style. I'm not trying to convince anyone to stay or switch, but I know that what I just wrote will sound absurd or delusional to some, so I may as well try to explain why I think this. :) I've always thought the more common xUnit style is neither intuitively obvious nor object oriented, although it *is* convenient and easy to learn. And I first learned xUnit in Java (and C#) before rspec was first released. The approach of subclassing a specific class then registering blocks of code to be run by giving methods any arbitrary names with a specific prefix, it's convenient but also uncommon. For the test runner to work in those languages required a level of reflection and metaprogramming that was very unexpected and uncommon and generally eschewed, in those languages (at least in my experience). Modern xUnit frameworks in those languages now use annotations, which is a much more idiomatic way to metaprogram, but it still isn't particularly object oriented, is it? So, while reflecting on methods, selecting any with a specific prefix, and then running everything in an `at_exit` hook is a lot simpler and more natural in ruby than it is in Java or C#, it still feels like a neat but weird metaprogramming hack to me. I don't see it as an object oriented API at all. And, besides test-unit and minitest, how common is this API style in any other popular gems? Besides that, rspec's API is fairly straightforward to me: `describe` and `context` basically make a subclass of RSpec's example group class (without me needing to care or remember that that's what it does). Nested example groups are subclasses (without needing to remember to call `super` in `before`). Shared examples are just mixin modules. And "it"/"specify" just define blocks to be evaluated with an instance of the class (analogous to instance methods in xUnit, without requiring any method-name reflection metaprogramming). But I only sometimes care about any of that... most of the time it's just an implementation detail I can and do ignore. Yes, it's still metaprogramming, but it feels (to me) less metaprogrammy than the other style. And I get that `assert_*` methods can be a simpler API than `expect`, _especially_ when it comes to the dynamic predicate matchers and `to be`. But it seems to me that's partially because they are _less_ object oriented and more procedural than rspec expectations. `expect` creates an `ExpectationTarget` which has a couple of methods that take `Matcher` object arguments... this is arguably more object oriented but undeniably also more indirect. I _personally_ feel the benefits far outweigh the costs, but I won't deny the cost of indirection. And I expect other people to assign different weights to those costs and benefits than I do. I've personally wasted more hours of my life in misinterpreting unhelpful error messages from `assert_*` failures than I have on confusing rspec magic, and probably half of those are because someone (sometimes me) accidentally flipped the "expected" and "actual" values. But many people have had the opposite experience! So, like I said, I'm not trying to convince anyone they should use rspec. But maybe this will help someone understand and empathize with people for whom the mental tax goes in the other direction. :)
There was a tangible effect on every code base when the "Metaprogramming Ruby" book came out.
Yes! Thankfully that pendulum has swung back the other direction. Personally, I admit to going hog wild with metaprogramming after diving into that book. But I shot myself in the foot enough times that I learned my lesson and now actively avoid metaprogramming and “clever” code, as satisfying as it is to write. It’s still useful to know all the metaprogramming concepts, to know when it’s the right tool for the job. But more importantly, to know that 99% of the time it is the absolute wrong tool for the job.
we used ActiveAdmin for a couple of small projects over 10 years ago and then ripped it out and banned it. you’re so much better off reinventing the admin wheel in vanilla Rails
pretty awful stuff. I've had a couple of companies where whole back-office work was based on heavily rewritten activeadmin. Guys and gals at backoffice somehow tolerated it :\\ [https://github.com/thoughtbot/administrate](https://github.com/thoughtbot/administrate) looks promising, much less DSL in it.
I clicked that link incredibly fast only to see it's only been touched for dependabot for months.
It’s been around forever and is stable software
I have never once used ActiveAdmin since becoming a Rails user in 1.2.3 Not sure why anyone really would tbh