The best way to write right java is either
1. DONT use it at all
2. If you are forced to use it, use java to execute an external application, and write that application in another language.

Testing Java code is increasingly a task taken on by developers rather than separate teams to which the programs are handed. Many Java developers are now familiar with JUnit and know the different between unit tests and integration tests. This has been driven largely by the focus on test-driven development (TDD) in extreme programming (XP) and other agile software development methodologies. While the industry-at-large has recognized the value of unit tests and has a new outlook on testing in general, for the most part, actual TDD (meaning, the tests are written first) is not usually practiced outside of hardcore agile shops.

Testing Java code is increasingly a task taken on by developers rather than separate teams to which the programs are handed. Many Java developers are now familiar with JUnit and know the different between unit tests and integration tests. This has been driven largely by the focus on test-driven development (TDD) in extreme programming (XP) and other agile software development methodologies. While the industry-at-large has recognized the value of unit tests and has a new outlook on testing in general, for the most part, actual TDD (meaning, the tests are written first) is not usually practiced outside of hardcore agile shops.

Though the development in question is a trivial one, your conclusions encapsulate perfectly why TDD is a poor substitute for a proper development model:

Conclusion 1: "It forced us to translate our ambiguous requirements into verifiable test criteria"

But on whose terms ? The "us" in your statement implies that you mean the developer. This is WRONG. An ambiguity must be flattened out by the specifier and agreed on by the developer. This is the contract you have with whoever you are providing a solution for. A developer is just as likely to interpret an ambiguity incorrectly as correctly.

Conclusion 2: "The test criteria helped us focus on doing just what was needed to pass the test, and thus hopefully satisfying the requirements"

Well, "hopefully" is not good enough. The objective of the developer MUST be to make their code do what it should in relation to the requirement. By encouraging a coder to produce something that meets only the requirements of a test that they themselves have defined is obviously a corrupt concept. Focussing on the test rather than the true objective of the requirement breaks a valuable chain of responsibility that should exist at every stage of the process.

Conclusion 3: "We avoided the heavy front-loading of design documentation and focused on getting some working code."

This is the icing on the cake. Spending time thinking about and documenting a design delivers too many obvious benefits to mention. However, in relation to the anti-patterns that I believe are a core part of your conclusions, designing a solution before implementing it would force any ambiguities to be resolved at the correct time and in the correct manner (against a coherent definition that is intelligible to the business and development communities). In addition, assuming that a solution involves more that one method (which of course it generally does) it would promote the production of a more appropriate test path with the requirements taking precedence over the tests themselves.