> Thanks, I'll update and try again.. Don't think I don't appreciate the > hard > work you are all doing, because I do.. I just want to see the quality and > confidence go up, which will ensure that the project will be more often > considered for use in various shops. For instance, I co-founded a Java-
I don't complain. Bugs are part of my life :-) I know XDoclet has the potential to become as popular as Ant. And we're just getting started, we have great plans for v1.2. > One method of doing this may be to use expect or do file comparisons. That Not a good idea IMO. A simple change in one of the sources and you have to update ALL comparison targets. For example let's say Dmitri adds support for something in jBoss, he then updates 4 source files, now we might have to change 4*6 files and update all expected test results, even a simple javadoc change (we copy javadoc to generated remote interface/home/etc). It's too much volatile. I think a better approach is to actually deploy it and *call* all those methods. So if something goes wrong (create methods disappears, etc) we'll get a compile time error. It's still a bit hard to test struts/etc form, should be accessed through web. So far we all relied on our personal tests, I test it on WebSphere on my project, Dim on jBoss, Aslak on WL, and so on. Anyway this method is good for generated code (hard to test TX_REQUIRED is indeed set for method x in generated xml), but for generated xml we check against DTD, but we could add an XPath test to make sure it there in generated xml file. We haven't reached the level to test the above scenarios, I think because we planned to reorganize samples to become smaller and more testable but we couldn't find enough time for v1.1 to do that. You know it's hard or unwilling to add tests to a huge already existing source tree :-) > Another method was one that was mentioned earlier, one of testing > deployment. This would involve deploying generated beans into JBoss and > Weblogic, and running unit tests against them to check logic, CMP/BMP, > etc. Yup. > These would involve more work but ensure that deployment occurs properly > (no > exceptions upon deployment) and that the behavior is expected (data in DB > by > testng with a straight SQL connection outside the bean or requerying the > bean and comparing fields for CMP and Castor JDO). My main concern on this > topic is that if you or others are only testing with one application > server, > issues could arise with another and not be caught. Its fairly inexpensive > (time wise) to download an eval of WebLogic or talk with them about a 2-6 > month dev license for testing your project as you do with JBoss. And of No fear of licenses, but time is money and we're all busy ppl :-) I would do that for sure if I was paid for. I can't tell my girlfriend to deadlock till I test it on WL too ;-) > Sorry for the long-windedness, I just wanted to ensure that I convey my > thoughts adequately and provide a good background and vision for what I > would expect to see come from XDoclet. If this doesn't align with your > goals, please let me know so that I may adjust my vision and technology > decisions. Appreciate. Ara. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
