David, Thanks for your thoughts on my unit testing problems.
This message is for information, in case anyone else should tread the same path... David H. DeWolf wrote: > You are correct. I'm not sure what your solution should be, but can't > you do one of the following: > > 1) create your own ServletContext implementation and tell ServletUnit to > use it I tried this, but ended up with another problem; this is an excerpt from my notes at [http://wiki.oss-watch.ac.uk/PlutoNotes]: I tried modifying ServletUnitServletContext.getServletContext to return 'this' in conjunction with a revised 'ServletRunner' setup that registers the portlets with the original 'ServletRunner' class, but this fails because it looks for the 'WEB-INF/portlet.xml' file in the 'portal' directory, when it is actually in 'testsuite'. Further analysis of 'ServletRunner' shows that it contains a single 'WebApplication' value, which in turn contains the context directory and path values. I also note that the 'ServletContext' implementation in uses a 'WebApplication' value to determine the location of a resource for 'getResourceAsStream', so the strategy of item (2) above cannot be used to serve different servlets from different context directories. This suggests that multiple 'WebApplication's must be created, and a common directory of path->'ServletContext' values be maintained. A static 'Hashtable' value in 'WebApplication' could serve this purpose, 'getServletContext' using this map returning a context value. I tried doing the change noted above, and the application ran a good deal further. But, eventually, the portal driver uses 'getServletContext' implemented by 'javax.servlet.GenericServlet.getServletContext()', meaning that attributes are not carried over from the ServletUnit environment. Consequently, the 'driverConfig' value set up for the testsuite is not defined, which eventually results in a null pointer exception. (The Pluto portal driver catches this and uses the exception stack-trace for the portlet rendering in place of the intended portlet content; this is more difficult to detect than, say, raising an exception when the target portlet cannot be located.) ... I am now reconsidering my options -- I'm not sure if it will be fruitful to pursue this path. (Replacing the javax.servlet.GenericServlet implementation that is accessed up by the Pluto portal driver might be an option...) #g -- > 2) explicitly set ServletContext attributes during test initialization > > 3) Submit a patch to ServletUnit to let you do one of the above. > > David > > Graham Klyne wrote: > >> I seem to have run into a limitation of ServletUnit for testing Pluto >> code. It >> appears that when the portal driver attempts to retrieve a >> ServerContext value >> for the target portlet, ServletUnit simply returns a hard-coded null, >> which >> (unsurprisingly) results in portlet invocation failure. Also, it is >> not clear >> to me that ServletUnit has the ability to deal with more than one >> servlet and/or >> context in a single run (i.e. it reads a single application's web.xml >> file, >> without any obvious provision for dealing with more). >> >> I may take a little while longer to look at the ServletUnit code, but >> it is >> looking as if I may have to fall back on using HTTPUnit to test via a >> running >> Tomcat instance, which will make the tests slower to run than I would >> have liked. >> >> Does anyone have any edifying thoughts, comments or pointers? >> >> #g >> > -- Graham Klyne For email: http://www.ninebynine.org/#Contact
