Uh no, it's to demonstrate that the code "works". The problem here is what it means "to work". Part of the usefulness of TDD is that you might not fully understand what it means "to work" yet, and the tests help you flesh that out.

Let me clarify, so you don't think I'm 100% ditching what you're saying versus stating it a different way. A test suite will tend to have BOTH tests for what the correct behavior *is* and also tests for what the correct behavior *is not*. In other words, what you're doing is defining the BOUNDARIES between correct and incorrect behavior. You're right in the sense that if your *strategy* is to write only *optimistic* tests (i.e. "proving that it works"), you'll miss subtle areas where the behavior isn't fully clarified (i.e. corner cases).

But here's the problem: for absolutely anything in the universe, there is an INFINITE number of things something *is not*, but only a finite amount of things something *is*. I've seen people go too crazy with using tests as a way of type-checking everything where smarter data types would have been a better choice, or performing a hundred "this isn't what I want" tests that could have been handled with a single "this IS what I want" test. My point is that you're supposed to program for the correct case, not design as if you always expect everything to go wrong. Write for the correct case, test for the correct cases FIRST, test for the EXCEPTIONAL cases, and write handling code for the things that are exceptional. Don't write an infinite test suite of what something is not.

CONCLUSION: Write the most EFFECTIVE tests you can that covers the most ground. Don't write *pointless* tests you have to maintain later if there was a better test. If a test covers a lot of logical ground by defining the boundaries of what something *is not*, then write the test for that. If it covers a lot of ground by defining what something *is*, write the test for that.

Planets are always fun to look at, for instance if you have decent optics you should be able to make out some of the colouration on Jupiter as well as some of the moons. The moon is also a good place to look, you should be able to see interesting shadows on the craters or if you have a half moon look that the line between light and dark you can get some interesting contrast there.

There goes another huge waste of our tax dollars. Now that we have had an expensive witch hunt we get the thrill of paying huge money to lock these guys up for no reason at all.
                And just why should the most conservative county get to hold power over all of us. How about letting the most l;iberal county declare when something is pornographic in nature?
                And I live near the center of Florida and nothing at all is offensive to me porn wise. So these judges are not representing the people at all. They are catering to the lowest element of dried up dullards. Sometimes I understand the loonies who go off and gun down people at random. It's because of nonsense like this courts rulings.

Take a careful look at what your Java program is actually doing, in whatever example applications that you have. If you then rewrote the same program in C++, to do exactly the same things, then it would be dead slow too. In fact, when certain widely encouraged programming practices are used, it can cause C++ to be very slow too.

If you sit down and rewrite the Java program so it doesn't do all the "idiotic" things that no normal C programmer would do, then Java is surprisingly fast. Hence the variability between different peoples opinions of speed in Java. Personally, I don't like the way Java makes it difficult to get an assembly printout. As such, I don't know when the Java compiler is making fast code or slow code. I think that is the real problem with Java is that it is so abstracted from real hardware that few programmers have any idea of what it is the average Java program really does.