Hi Jeffrey, Jeffrey D. Brekke wrote:
I like your approach, and we've done something not very similar. In our enviornment we purposely removed our 'outside' tests ( httpunit functional tests ) from our code that implements the application. They are in fact in different projects altogether and the httpunit tests do not depend on any code from the system itself. This way we can fully test the system from the 'outside'. It does have the drawback that you've solved using static accessors though. I think it is nice to have the action/formhandling code and the template be in sync.My test code is in a separate project too. I just include classpath access to the jar file of the main code in order to access the static items. I guess one could work on making the access completely restricted to this ....
However there are interesting issues. For example, say you have a web screen that allows the user to specify a url. The url is then parsed and some statisics from that page are displayed. How does the httpUnit test check that these statistics regarding the url are correct? Clearly httpUnit tst needs to access the same statistical methods that are in use my the implementation.
I guess one might argue that this functionality should be unit tested separately, but that kind of misses the completeness of the black box test. I guess one solution is to make the necessary functions available to the httpnit tests though otehr packages. Of course these tests would not pick up fundamental errors in the third party, or seperate packages, but that is another story ...
In our testing I found that we've used httpunit for two things: test drive the app from the users perspective and verify the html is generating correctly. From a programmer/developer perspective, it would be nice to have a way to render a template for testing to verify it is correct. It may not have to function, but test that there are no velocity/rendering issues.interesting. doesn't httpUnit sort of do this automatically when it accesses the html generated from the template? If there were velocity/rendering issues the correct html would not have been produced?
The driving of the application could/may then be slightly under the UI, say maybe just accessing the model or something.Right. This is one of the main things I am trying to address. I don't want to spend lots of time writing httpUnit tests and then spend lots of time re-writing them when the interface design changes. Some people have recommended servlet level testing (with cactus, or ServletUnit) to avoid the GUI dependency, but then the GUI is still not being tested.
Another drawback to how we've used httpunit is that the interface is tightly coupled to the tests now. Changing around the layout of the page, even if it didn't change functionality much, has a nasty ripple effect. We are now trying to reduce this coupling when possible.
In order to try and solve *all* my problems :-) I have started to implement the system I described in my original mail. I will scan my gui templates to generate outlines for my test classes and http-form handlers, and then when my gui changes I can re-scan them and regenerate the outlines. I guess the outlines would be better off as base classes that the actual test and form handling implementations would extend, in much the same way that torque generates base classes from a data description. Update your data model and the base classes are adjusted automatically ....
I guess ideally one would be able to specify the GUI components in XML (as torque specifies its data model in XML), but since I have limited resources I'm going to start with HTML template specification of the GUI and see how far I can get.
CHEERS> SAM
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
