> On 9/17/05, Gary VanMatre 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. >
Yep, I'm all for that. I know that there are some folks from my neighborhood that have come to shale just for the jsf testing framework. > 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 :-). > I'll move my change to the mock context since you think it will apply globally. > The remote usecase test cases also implement the response getWriter(). > > > > That also seems like something worth generalizing into the standard mock > objects. > I'll add a setWriter to the response too. > 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. > And, I'll refactor this one too. The setRequestParameterMap sounds like it's the ticket. > > 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. Maybe we should make these Mock classes final to discourage what I've done :-) > > Gary > > > > Craig > Gary
