On 30 Apr, Sheldon Wosnick wrote: > Laurent, > > Thank you and perhaps I was too verbose. I understand the structure of the > runtime and the classpath. What I don't understand is why certain test > classes (the code you write, not the runtime distribution from Cactus) are > duplicated on the client and the server. I have read the classpath setup at > http://jakarta.apache.org/cactus/howto_classpath.html but > > "What's missing" is what test case code goes on the client side and what > test case code goes on the server-side -- not where to put it, not what jars > and configuration files. >
All the tests cases go on both client and server. If I understand correclty, all beginXXXX() and endXXX() methods are executed on the client and the testXXX() methods are executed on the server. > Ok, here is what I mean. For a simple servlet redirector test case, say > TestCase1, what would be the structure on the client and on the server? > Both. > Am I missing something that this seems so obvious from a reading of the > various literature in print on using Cactus, I am led to believe that there > is an intentional duplication of some classes on both the client and the > server and I am trying to understand that. > It's necessary because you can't put the beginXXX() and endXXX() methods in a separate calss. > Is it simply says there that: > > Client-side Classpath: > ... > your test classes > ... > > > Server-side Classpath: > ... > WEB-INF/classes/<your test classes> > ... > > > I am trying to understand WHICH test classes go where. Not j2ee jar or > runtime jar files, only Test case code. > Anything that extends ServletTestCase or JspTestCase or FilterTestCase goes in there. If you're only extending TestCase, you don't need to put the classes in the web app (because most likely, you aren't testing any J2EE stuff). > I believe I read a chapter on Cactus on an XP, Open Source tools book by > Wiley recently about certain test case classes being on both the clieht and > server classpaths. In my environment that translates to separate projects so > that is why I ask. > Oh.... Conceptually, your client makes an HTTP request to your server and it executes that request. It just so happens that in this case, your client and server are in the same test file instead of being a human and a machine interacting. Now if you say your client and your server are different, I don't think Cactus is what you're after. I could be wrong, don't take my word for it. It really depends on what you're trying to test. If you're trying to test methods from your J2EE objects, then Cactus is your friend. If you want to test user experience (i.e. simulate a user accessing your servlet, clicking on a button and looking at the generated HTML), I think HttpUnit is more suited for that. But I'll let Vincent be the final authority. L -- Laurent Duperval <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
