Isn't this a question of whether to test generated code or not, or to what degree to test it? I would probably not write tests for the CMPs themselves -- I'd trust that the appserver implements the spec correctly. Then again, I'm not practicing TDD at the moment.

I developed CMP Beans on WAS 3.5 using TDD- it was kinda silly- because so much of the code is generated for you(just like in Xdoclet)- by Visual Age/WSAD. Its a little different doing point and click type development with TDD- maybe with the exception of custom finders(which you need to hand code). However, the Junit tests that were derived as a result were valuable-I could change the CMP- then tweak the Junit class and run it- and know that my code was solid. I guess that is true wherever Junit is used....

I always get a little worried when I see statements like "my next project will use X technology, how do I use test-driven development with it?" I can't help feeling that the person asking the question has missed the point of test-driven development a bit. In test-driven development you let the tests guide you toward the correct technology. Every time you make a decision before writing any tests, you are constraining what you can learn from your tests. It might be that your project doesn't actually need EJB CMP, but can be done in a much simpler and easier way. Can you describe a little more about what your project is intended to do - what benefits should it give to customers or users ? Once you have some stories about what it needs to do, then you can start writing tests, and then you can start writing code to make those tests pass.