Maybe you should look at a real system for constructing proofs, such as Haskell, or Epigram. My experience with Haskell is that the effort required to construct the proof is greater than the need for the proof. All I really need is some confidence in the code, usually. There may be cases where I need real proof, and that is when a type checker may be useful.

I’m not saying that automated tests are useless, merely that applying a rule that states that they should always be done before writing the code that they test, is likely to be harmful. Also, that the intermediate stage, where you write naive code to make a single test pass, is also harmful.

Using your example, it’s obviously very simple and doesn’t require a wealth of tests, but I still think you need to at least test if it works under valid and invalid conditions. Yes, we both know how it works now, but what happens when somebody replaces { return x; } with { if (x == null) return new NullObject() else return x; }.

These examples are a bit contrived though, testing something as tiny and abstract probably wont fall into the usual realm of testing. As long as these methods are covered in your other more substantial tests then I probably wouldn’t worry about them.

I disagree – you should write the method properly in the first place. If you don’t, then even the first test case is useless.

In terms of coverage, if that refers to whether lines are executed or not, consider the identity function:

(lambda (x) x) (or, in Java, Object id(Object x){return x;}).

If I write my test for that to only test for 5, it makes zero sense to write the identity function as (lambda (x) 5) (or, return 5;).

The identity function is so simple that it really doesn’t need (runtime) tests anyway, of course, but what is plain is that you get complete code coverage of it from one test. Writing ten tests for it doesn’t improve matters. As soon as your test code is bigger (conceptually, not necessarily in lines of code) than the code it’s testing, you’re probably trying to prove through testing, which is usually impossible.

I’d suggest you use testing to give yourself confidence, not to prove things. Proofs can be constructed with other tools, such as type systems (or with your brain).