I think the challenge of writing any good coding resource is balancing philosophy with content. Most books and articles swing far into philosophy with little assertion to back it up, usually at the cost of content. The authors always forget that the reason I bought the book or opened the article is because I am, 99% of the time, already sold on the philosophy, idea, programming language, [flavor]. The Tests article offers little substantial content and doesn't bother to offer up any specific examples. Yes, there is a mention of RoR and its ORM, but then it concludes: "Well designed code will never substitute testing, but does give you the reassurance that no code coverage can match." In regards to this, I think Rich Hickey said it best: "gem install hairball."

http://www.joelonsoftware.com/navlinks/fog0000000262.html

I'd like you to think about the TDD article harder -- testing isn't easy, and asserts aren't substitutes for good tests. Just because an ORM solves SQL injection doesn't mean it has protected you against bad data. And how do you have confidence that pending changes don't regress prod? Asserts are great for bailing at runtime (which nobody actually wants in practice), but they haven't yet found use at predicting which builds will fail. For that you need sample inputs, and these sample inputs are the basis of every test :)

Also, coordinating multiple processes/threads/drones/ect is easy when the mutex is reliable and transactionally safe. Often neither is true, especially for systems that scale to tens of millions of users and have their data partitioned or in volatile containers. What patterns should developers consider?

Regarding submission of articles, I'd like to work with authors earlier in the writing process rather than just receive a bunch if completed work that may not be right for the site. However, even that should more transparent, I agree.

His argument is not to abolish tests and use asserts, but rather to define a set of cases for which you would not need to test because the framework, by its nature, makes it unnecessary.

His example was SQL injection. (a) If I were to write my own MySql queries which directly talk with the DB, then I would need to write tests around those query to make sure it is not possible to execute SQL injection. (b) If I am using an ORM that comes with feature so I don't write the sql queries, it creates it on its own and also comes with the feature to handles possible use-cases which would normally lead to SQl injection, in such case, there is no need to write the test.

Thanks for letting the need for a feed be known!

I'll def read your post and follow up.