Actually I think Web 1.0 was reminiscent of the mainframe terminal environment. Struts immediately jumps to mind. Web 2.0 reminds me more of client / server applications although its not a perfect analogy.

It should not be surprising that architectures keep shifting back and forth over the years. Each is in some sense solving certain problems of the former. But it does lead to a certain amount of "rediscovering" something that used to be well understood. I suspect that many of the younger folks would be surprised to know that the virtualization driving the cloud dates back to 1972 and the IBM System/370 range of mainframes.

I like unit testing as a tool but I get turned off by a lot of pro-unit testing comments because people tend to describe in terms of something that must always be done or the code is of questionable quality. There are many situations where unit tests can't be made in a meaningful way.

The system I work on depends on real-time data streams to provide the context that defines how something is processed. Yes I could make unit tests for each of the simple operations, but what is complicated is the way the real-time data can trigger those simple operations in so many combinations and permutations. It is not practical to write a set of unit tests where each has a precondition of setting the full system state. The typical response I get is 'Well at least write unit tests for the part that is unit testable.' My response is that the part that isn't unit testable is the interesting part. Any technique is a trade off between the effort to use it and value it returns. Writing unit tests for simple code that can be verified through visual inspection is unlikely to return the value that justifies the effort.

Unit tests are great where they can be applied effectively but like any technique should not be applied slavishly to every situation.

Yeah you are right. Thanks for correcting my mistake. Serves me right for trying to make a post before first coffee.