Seems to me that if you are asking this question, you shouldn’t be in this business. I can’t imagine moving on to another career. It’s one thing to only write code at work and not as a hobby. If I had a billion dollars and could retire tomorrow, I’d still be writing code all day because it is what I like to do. I think it is another matter if you are already thinking about a post-programming career.

The thing which makes testing nomenclature worse is that the tests themselves aren’t all that different, or at least, they are often not different enough for us to for us to distinguish them without being told. Yes, we can tell the difference between a unit test and an acceptance test in most systems, but really there is no force which prevents tests of different types from bleeding through into each other.

Right on, right on, right on! At work, we have at least four different types of testing: unit testing, integration testing, system testing, and customer acceptance testing. The only real distinction I’ve seen is between unit testing and the rest of the test types.

I also write and execute the integration tests, and I have to tell you, the types of tests seem identical to system and customer acceptance tests. I’m told that the tests use different data and have different focuses, but like Michael points out, I had to be told. And I’m pretty sure I have a draft post filed away somewhere about this topic.

Misko Hevery also hits on a work-related nerve of mine, stating that “there is a myth out there that creating objects is expensive.” This myth is such a fact at work that “object design”, if you can call it that, is heavily driven by the result sets of a stored procedure, the needs of a UI page, or caching opportunities. This, in turn, is due to the performance demands we place on multiple JVMs running on multiple servers.

I’m sorry. If you have such strenuous demands for memory and resources in your production run-time environment, then maybe you’re doing it wrong. Maybe you shouldn’t use a language like Java if the programmer productivity benefit from the higher level of abstraction is going to be offset by C-like edicts on objects, or lack thereof.

If they’re going to make us write procedural Java, why not take away the performance hit by moving to C?