[Terretta]

> You really need to go at least this far.

"The framework don't care."

What I mean is, the framework doesn't know if you're building the result of 20 queries into a blog post page that pulled in related data from the post itself, the author profile, and the comments and commenter profiles, or if you're pulling in arbitrary data. So there's no reason to test a "blog". Most of us aren't building blogs. But we are interested in querying databases, calling web services, cached performance, and async process queue handling.

[kbenson]

Except that I, and I'm sure many other people, are interested in more than just performance. I want to know how much code it is to achieve some small subset of usefulness, and what it looks like. Is it overly complex? Is it split apart in a paradigm that doesn't match my mental model very well?

I agree most of us aren't building blogs (I'm not), but I believe a blog is a reasonable stand in for a more complex application. It obviously won't test everything, but the requirements are well understood (or can be well understood, if defined well enough).

Also, who's to say that some of these frameworks aren't going to perform significantly worse when they start having to do more than simply serialize data as JSON across a socket? With that in mind, how accurate are some of these benchmarks if they aren't set up and used how they would be in real life.