Earlier quoted context omitted.
>An actual specification layer isn't any simpler than the execution layer. The point of separation of concerns isnt to keep the simple layer separate from the complex one. It's to simplify the whole thing by only addressing one concern per layer. Unit tests are often a pain in the ass to read because they are a mess of implementation and specification details. No separation. >You can't solve the problem in that way.…
Oh I understand the standard arguments. I just don't agree with them. > The point of separation of concerns isnt to keep the simple layer separate from the complex one. It's to simplify the whole thing by only addressing one concern per layer. With some caveats, I think this is just a fiction. There can be some value in having high-level tests and low-level tests, but not because it removes complexity. It can help wi…
I think the problem here is that you are substituting standard arguments for my arguments.
>With some caveats, I think this is just a fiction. There can be some value in having high-level tests and low-level tests, but not because it removes complexity.
Separation of concerns isn't about having "high level" and "low level" tests. You don't have "high level" views and "low level" views in MVC. You have views and controllers and you keep them separate because otherwise you have an old-skool PHP-like mix of SQL and HTML all over the place.
That PHP style mess happens to most tests because the code that is intended to describe behavior is mushed up thoroughly with the code that attaches to the app and executes it.
If you separate the concerns, the test becomes readable and even serves as a spec.
>But this is exactly what they want you to do, and do well enough that "that's not what i meant" is not a big problem.
The problem is rarely that they didn't say what they mean. The problem is that once you've built the thing or walked them through a crystallized user story it makes them rethink what was actually needed. In many cases I've walked stakeholders through user stories and they suddenly realized no new feature was necessary.
>They certainly don't want to read cucumber tests
Nobody does, but that's because cucumber tests have abysmal syntax and UX, not because the idea of readable spectests was intrinsically bad. Throwing away spectests as a concept because cucumber is bad is like throwing away programming as a concept because COBOL is bad.
>They will tolerate rough, incremental prototypes
Of course, which is not as expensive as a fully fledged app but way more expensive to build than crystallized user stories. I prefer the cheaper option.