Hi Joe, I don't know if this is the correct way to do it but if you call setupGetAttribute on the MockServletContext with the key that you require and a null value, when the code you want to test calls getAttribute it will get a null value (which I assume is what you want in the test) and the AssertionFailedError will not be seen.
I think the idea is you call setupGetAttribute with each attribute you expect the code you are testing to try to get even if you want the code to receive a null value. If the code attempts to get an attribute which you haven't told the MockServletContext about you get the AssertionFailedError. HTH Regards Gareth Webbley On Tuesday 23 November 2004 00:05, Joe Germuska wrote: > I just found an annoying bug in struts-chain, where CreateAction was > looking up the map of actions under one key, and if not found, > creating a new map and storing it under another key. The net result > being that every CreateAction request was resulting in the > initialization of a new Action class (as well as a new HashMap). > > Anyway, I thought this would be a good time to start writing test > cases for struts-chain stuff. I haven't used MockObjects much, but > it seemed like the best way to set up the mock environment. However, > when I got down to running the test, I found that the library appears > to be hard-coded to throw an AssertionFailedError if you try to > retrieve something from the MockServletContext which isn't there. > > http://mockobjects.sourceforge.net/javadoc/1.4/com/mockobjects/ReturnObject >Bag.html#getNextReturnObject(java.lang.Object) > > Does anyone more familiar with MockObjects know if there's a way to > turn off this behavior or otherwise specify that it's not an error > condition? Obviously in this case I can't write a test case for my > fix if I can't simulate the condition where there is not yet any such > object in the ServletContext. > > I went ahead and committed the fix anyway (rev. 106242) but it would > be nice to be able to test it. > > I'm going to go ahead and commit the project.xml file that has > mockobjects dependencies, since they may still be useful for other > tests that we may want to write. This project.xml file also fixes > the inheritance from the Struts project.xml file. (For the el > libraries, I did this the other way, by copying the files that would > otherwise be picked up by inheritance. I'm not sure which I think is > more "right" but the inheritance precludes someone from building a > source distribution, which is kind of a drag. In this case, it was > just faster!) > > Joe --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
