On 9/17/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > On 9/17/05, Gary VanMatre wrote: > > > > > > I was thinking that it might be helpful to have some protected factory > > > > methods on the AbstractJsfTestCase for instantiating the environment > mock > > > objects like request, response, faces context, ... > > > > > > I can see why one might want to do that, if the default implementations > that > > AbstractJsfTestCase wires up are insufficient. I haven't found that to > be > > the case ... have you? If so, I would think we'd want to enhance the > > functionality of the framework's mock objects where appropriate, no > matter > > what we do about adding protected methods to the abstract test case > class. > > >
As you might imagine, I'd much prefer making the test framework mock object implementations more suitable before encouraging users to do their own implementations. As such, it's going to take looking at each of your use cases below to see what we might be able to port into the general architecture, where we might just say "your test environment doesn't look enough like a webapp ... so change it!", and where we might say "we really need pluggable mock objects here." The initial mock objects implemented (selfishly :-) only the stuff I needed to do the unit tests I was already building ... and you've probably seen me flesh out additional implementations on them as subsequently developed tests have needed more behavior. I would *much* rather see us evolve the test framework's mock objects to suit the needs of the developer creating unit tests, rather than force them to create their own subclasses. I've had to change the behavior to getResource(String path) on the servlet > context for the clay config test case. > Your changes look generally useful here. I admit that I was lazy implementing this part of the ServletContext contract :-). The remote usecase test cases also implement the response getWriter(). > That also seems like something worth generalizing into the standard mock objects. The rolodex test case also extends the external context (This one is kind of > a kluge). > Yep, that is definitely a kludge :-). The design intent is that you'd call addRequestParameterMap() or setRequestParameterMap() yourself, after AbstractJsfTestCase did its initial wiring of the related objects, to configure what request parameter information will be exposed to your test case. > This would be a place that you could override and provide your own mock > > > implementation for a test case and not have to try to hookup all the > > > references. > > > > > > My only concern is that having an application provide its own mock > objects, > > instead of using the ones provided by the test framework (which will > have > > presumably been tested fairly extensively due to wide use) would lead to > a > > potential for hidden bugs due to flaws in the application's mock object > > implementation classes. > > > True, we don't want to have to write a test to test our test :-) > +1. Gary > Craig
