Robert Martin says in clean code, or maybe clean architecture, that one should separate the tests into what is hard and easy. GUI tests are hard and therefore brittle and so we should test against view models.

However on clean agile he says a story is not done until it passes automated acceptance tests which in my experience are always brittle and grow so large and brittle that things grind to a halt.

What am I missing? Are stable acceptance tests possible on the GUI? Should we test only an API?

Nothing is set in stone, whatever fits the workflow or the situation.

GUI tests don't have to be hard.
input: fake api-data for article
output: rendered HTML page for the article
test: check if the H1 has the specified title.

That's easier than testing a viewModel - which might require you to restructure your code into testable units.

The harder part is if you have interaction or multi-part flows like three step form where you click a button and after 0.3s a modal pops up.

I think the value of end-to-end tests is far greater than unit-tests.
The obvious benefit being that unless your test covers the view rendering it's not worth a whole lot - who cares if the model has a title if you forgot to output the title in the view.

Another thing is: test readability.
If I look at someone's unit test, there's a bunch of internal structures which I might not be familiar with.
But if I look at someone's end-to-end HTML test I can see what they're testing for. I can compare it to the production site. I can even paste the result into a browser and take a look to visualise it.

Both are of course nice to have but I'd easily prioritize pic end-to-end tests if I had to.
Often we can get away with not testing every other brick - just the ones which are load bearing. 😏

I always test a units which are extra complex: like tests for a regex are a given.

But in general I find that most of my errors don't occur in individual functions, but rather in the way they use each other.

@jiraTicket I disagree but to each their own.

My reason though is that unit tests don't just prove working code, for me that is secondary. They're about refinement, refactoring, documentation, clean black box design, clean code if used correctly.

Difficult to read unit tests are not clean. Unit tests should be of the same high quality as the rest of the code base, and in my opinion they should be written in abstract steps.

Eg
SetupUserWithLockedLogin();
Assert_loginFailed_frameworkSyntax();

End to end tests solve a completely different problem for me.