| I think you might be reading into it a bit too much. The author is saying that this code > reads exactly like how a person might talk about what they want to test A person WOULDN'T talk about testing a Ticket like what you're describing with implementation details "Ticket is a class, which will have a method of _this_ and I will call that method, which will then do _that_, and I will take the return of that method and call put it in a variable, that will be a constant..." A person WOULD talk about testing a Ticket high level like this "Let's describe a Ticket. When the ticket is closed, it emails the requestor with a confirmation." Now listen, obviously not being familiar with the syntax makes reading code harder, but a programming language isn't designed so that people can just look at the code and learn the syntax from looking at the code. That wouldn't make sense. With that said, I struggle to see some of your points listed as non-intuitive. All of your comments are related to not understanding the implementation details of this code. And that's just not what's being talked about here. I often see complaints about this when people are uncomfortable accepting _syntax_ that clearly tells them _what_ will happen, but if they don't understand HOW that happens, they don't like it. Here's another Rails example, for validating a model
```
class Person < ApplicationRecord
validates :name, presence: true, uniqueness: true
end
``` Can you seriously say that you don't understand that the name of the Person will be validated if it is present, and if it is unique? I doubt that very much. Can you say that you have no idea how it's implemented? Yes. You don't know how something might be implemented in a language you don't know. But, does that really matter when talking about expresiveness? |