Dear Hani, Cedric and Jeanne
First of all thank you very much response to my questions, I didn't expect it :-)
To Jeanne, my questions are all framed at developer level testing. I am very cynical when it comes to Quality Assurance level testing, mainly because of my experience, the Quality Assurance Managers' bonuses were based on getting a higher CMMI level during assessment and so for them quality means ticking boxes on checklists. To be fair R&D centers in China are full of fresh inexperienced graduates and a high CMMI rating implies that they are mature enough to get the job done.
To Hani, I really struggled with Cactus and turned to HtmlUnit, but that meant that the test cases generated were leaning towards functional tests rather then unit tests. At the moment I am working on a lot of legacy code (mixture of Korn Shell scripts and Perl). We are now creating a lot of functional tests, just as you say. Our users/customers give us bug reports :-) and our new policy is to create an automated test case first using Perl's Test::Unit, then fixing the bug or developing the enhancement. So I feel we are definitely moving in the right direction.
To Cedric, I worked for Siemens in Nanjing and now work for HP in Shanghai. As I say my colleagues are generally fresh graduates and I believe they are genuinely passionate about coding. You have however hit the nail on the head, we are testing legacy, boring code. It is the nature of the business I believe, to reduce development costs by moving support and maintenance of older code/products to low cost countries.
My second question was phrased badly. Let me put it into context, testing and process. We write test plans, then test cases, then execute the test case and write test reports. There is a lot of duplication of effort, e.g. the textual description of a test case goes into the test plan, test case and test report (sure you can cut and paste). However having a centralized xml file as a source manuscript for all would be ideal. One that works for TestNG and also perhaps Apache Continuum and is the bases of my test plan and is the descriptive input to my test report, output as a pdf. Thus the bureaucratic aspect of testing is covered by one or two xml files and a set of tools. A testing framework should offer that shouldn't it?
Although I have to admit my original question was hinting towards the fact that this is another xml/configuration file, on top of many others and may pull people away from using conventions, defining convention busting test cases simply because they can using. I guess I am still a little skeptical of the xml panacea ;-)
Finally I do feel reinvigorated about testing and will during my lunch breaks talk up testing as the new cool thing and those who don't test "just don't get it".
Once again thank you very much for your answers, they are very much appreciated by me.
Andrew