On 8/2/05, David Thielen <[EMAIL PROTECTED]> wrote: > Hi; > > > > For those that hit the same problem - you need to call super.setUp() and > super.tearDown() in your setUp/tearDown. >
Yep ... if you're extending the abstract base classes you definitely want this. We should make that clearer in the Javadocs. > > > Also, servletContext.getRealPath() is not implemented in the mock objects. > Is there a reason why it doesn't return the default directory? > Seems like a reasonable RFE -- the only potential gotcha is if your test environment doesn't set up something that looks like a webapp directory structure (and mine certainly don't). Thus, it might be better to have a setter on MockServletContext so an individual test case can set this to wherever it wants, in its setUp() method, when it knows that the surrounding directory structure has the right "shape". By the same token, the ServletContext.getResourceXXX() methods could then be implemented too, based on the same base directory (or URL). > > > Finally, I need to determine at one place in my code if I am running as a > test or for real. Any suggestions on the best way to do it? > Hmm ... guess the mock environment is too good a fake for you, huh? :-) Two possibilities I can think of: * Check the class name of, say, the ServletContext instance your app receives. You'd want to do this by class name, rather than instanceof, in order to avoid creating runtime dependencies on the test framework classes. * In JavaBeans, there is a Beans.isDesignTime() call that is often used to tell components that they are running in a design time environment (such as inside an IDE) rather than at runtime. We could sorta cheat and have the base test case setUp() method set this flag, so your application code coud use it. > > > Thanks - dave > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
