4 ms·

I never met Sapir or Whorf. My hypothesis is that libraries like RSpec which offer a thin "rephrasing" veneer over the assertion-based test module are a waste o

I never met Sapir or Whorf. My hypothesis is that libraries like RSpec which offer a thin "rephrasing" veneer over the assertion-based test module are a waste of mental capacity (and this goes triple for Cucumber and other similar regex-based trash). The specification goes in the test title and if necessary, a comment. Then the programmer writes code to test the spec. I've never understood what is suboptimal about this. Why do developers need to be tricked?

8fGTBjZxBcHq 5y ago
Honestly I just like the flow of it a little more aesthetically and I've never been so restricted on mental capacity that I noticed the extra burden. Condolences though.
nitrogen 5y ago
Why do developers need to be tricked? 1. Variations in preferences. Given that every brain is structured a bit differently, and that every person has different backgrounds and experiences, it's reasonable to conclude that different syntax or vocabulary will make things "click" for different people. This is evidenced by the fact that there is more than one programming language in daily use. 2. Cognitive burden. We're all smart enough to learn whatever syntax, framework, or vocabulary is necessary to accomplish a task. But if there is a different way of structuring common tasks that flows better for someone, then choosing that flow over something more traditional frees up that tiny extra bit of mental effort for other tasks. These optimizations accumulate, so even a very smart person can benefit from doing easy things in the easiest way for them. Then, teams benefit on top of that from the reduced communication burden.
blacktriangle 5y ago
I'm right there with you on RSpec. We're programmers, we think in code, we think in the native primitives of the language. Now you bring in RSpec equality and comparison operators and I have to go look up RSpecs semantics vs just leveraging all my existing Ruby knowledge. Cucumber otoh is an absolutely amazing tool...in the correct organization. When used as it was designed, ie analysis's working with stakeholders to gather requirements which can then be turned into executable tests for the developers to conform with is amazing. Its when developers start writing cucumber features without talking to anybody else that the whole thing becomes pointless.
bhaak 5y ago
This doesn't sound like you ever programmed RSpec tests? Edit: To expand on that. I thought I knew and understood the model–view–controller having only read about it. But only when I actually used it in early RoR version I truly understood what kind of advantages and disadvantages this approach had. The article explains the reasoning of RSpec and I'd say it should answer your questions.
judofyr 5y ago
> The specification goes in the test title and if necessary, a comment. Then the programmer writes code to test the spec. I've never understood what is suboptimal about this. Why do developers need to be tricked? I think there's a combination of things in play here which caused RSpec to take off: - RSpec's matchers were a bit more expressive than the built-in assertions. This meant not only that you could write "should_be_greater" and when an error occurs it would present it in a much nicer way ("expected result to be greater than X, got Y") than the simple "assert". - For many people when getting started with TDD/BDD it does help to start from a library/toolkit which has the concepts built-in. A good example is being able to actually write full sentences for the test name instead of being forced to summarize in snake_case. That said, I do find the current RSpec expectation syntax to be annoying and over complicated. And that's not because I don't like DSL, but because I think that this DSL is focused on making it readable as an English sentence instead of trying to build its own language with its own primitives. Example: expect(result).to eq(3) - `eq(3)` I can understand: This creates an assertion. This knows how to validate the value and how to format the error message. Having these as standalone objects seem to allow some pretty cool usages. - However, what is expect()? What does it return? What does that object represent? Why is there a to() method? What other methods are on `to`? It seems to me that this could have been solved by a single method: expect_match(result, eq(3)). Yes, it doesn't read as an English sentence, but it's easy to understand the components: You have the assertion which is a standalone object, and then you have the `expect_match` which checks a result against that assertion. `expect_match` belongs to the test runner because we want it to fail the test if the assertion fails. And when you look at comparisons it's even worse: expect(actual).to be > expected I've been writing Ruby for over 10 years and immediately I struggle to parse this line. I guess `be` is a local method (coming from what module?) which returns an object whose only purpose is to convert operators into an assertion? To make things even more confusing, you can also write `expect(actual).to be`, but that is something completely different (it passes when the result is truthy). And here's the problem: The be() method doesn't actually serve any useful purpose in the "language" of matchers. It doesn't provide anything that couldn't have been accomplished within the existing framework. It's only there as a placeholder to make the whole expression read as an English sentence instead of `expect_match(result, gt(3))`.
- 5y ago
cageface 5y ago
I use Minitest over Rspec whenever I can in new Rails projects. The ecosystem of tools isn't as rich around Minitest but I spend a lot less time trying to remember various bits of the Rspec DSL and less time deciphering my colleauges' overly clever Rspec code. Rspec was a product of that era of DSL mania in software that has thankfully passed.

8fGTBjZxBcHq 5y ago

Honestly I just like the flow of it a little more aesthetically and I've never been so restricted on mental capacity that I noticed the extra burden. Condolences though.

nitrogen 5y ago

Why do developers need to be tricked? 1. Variations in preferences. Given that every brain is structured a bit differently, and that every person has different backgrounds and experiences, it's reasonable to conclude that different syntax or vocabulary will make things "click" for different people. This is evidenced by the fact that there is more than one programming language in daily use. 2. Cognitive burden. We're all smart enough to learn whatever syntax, framework, or vocabulary is necessary to accomplish a task. But if there is a different way of structuring common tasks that flows better for someone, then choosing that flow over something more traditional frees up that tiny extra bit of mental effort for other tasks. These optimizations accumulate, so even a very smart person can benefit from doing easy things in the easiest way for them. Then, teams benefit on top of that from the reduced communication burden.

blacktriangle 5y ago

I'm right there with you on RSpec. We're programmers, we think in code, we think in the native primitives of the language. Now you bring in RSpec equality and comparison operators and I have to go look up RSpecs semantics vs just leveraging all my existing Ruby knowledge. Cucumber otoh is an absolutely amazing tool...in the correct organization. When used as it was designed, ie analysis's working with stakeholders to gather requirements which can then be turned into executable tests for the developers to conform with is amazing. Its when developers start writing cucumber features without talking to anybody else that the whole thing becomes pointless.

bhaak 5y ago

This doesn't sound like you ever programmed RSpec tests? Edit: To expand on that. I thought I knew and understood the model–view–controller having only read about it. But only when I actually used it in early RoR version I truly understood what kind of advantages and disadvantages this approach had. The article explains the reasoning of RSpec and I'd say it should answer your questions.

judofyr 5y ago

> The specification goes in the test title and if necessary, a comment. Then the programmer writes code to test the spec. I've never understood what is suboptimal about this. Why do developers need to be tricked? I think there's a combination of things in play here which caused RSpec to take off: - RSpec's matchers were a bit more expressive than the built-in assertions. This meant not only that you could write "should_be_greater" and when an error occurs it would present it in a much nicer way ("expected result to be greater than X, got Y") than the simple "assert". - For many people when getting started with TDD/BDD it does help to start from a library/toolkit which has the concepts built-in. A good example is being able to actually write full sentences for the test name instead of being forced to summarize in snake_case. That said, I do find the current RSpec expectation syntax to be annoying and over complicated. And that's not because I don't like DSL, but because I think that this DSL is focused on making it readable as an English sentence instead of trying to build its own language with its own primitives. Example: expect(result).to eq(3) - `eq(3)` I can understand: This creates an assertion. This knows how to validate the value and how to format the error message. Having these as standalone objects seem to allow some pretty cool usages. - However, what is expect()? What does it return? What does that object represent? Why is there a to() method? What other methods are on `to`? It seems to me that this could have been solved by a single method: expect_match(result, eq(3)). Yes, it doesn't read as an English sentence, but it's easy to understand the components: You have the assertion which is a standalone object, and then you have the `expect_match` which checks a result against that assertion. `expect_match` belongs to the test runner because we want it to fail the test if the assertion fails. And when you look at comparisons it's even worse: expect(actual).to be > expected I've been writing Ruby for over 10 years and immediately I struggle to parse this line. I guess `be` is a local method (coming from what module?) which returns an object whose only purpose is to convert operators into an assertion? To make things even more confusing, you can also write `expect(actual).to be`, but that is something completely different (it passes when the result is truthy). And here's the problem: The be() method doesn't actually serve any useful purpose in the "language" of matchers. It doesn't provide anything that couldn't have been accomplished within the existing framework. It's only there as a placeholder to make the whole expression read as an English sentence instead of `expect_match(result, gt(3))`.

5y ago

cageface 5y ago

I use Minitest over Rspec whenever I can in new Rails projects. The ecosystem of tools isn't as rich around Minitest but I spend a lot less time trying to remember various bits of the Rspec DSL and less time deciphering my colleauges' overly clever Rspec code. Rspec was a product of that era of DSL mania in software that has thankfully passed.