JFileChooser JUnit Testing

If a student needs to test a method that contains a call to JFileChooser or some such dialog, the tests will fail due to lack of permissions (I assume due to sandboxing). In such cases, do you resort to creating "dummy" classes that mock the real ones but without the functionality? Give the student permissions so the test can complete? Or, exclude all such methods from testing? I'm just looking for how any of you have handled similar situations in the past.

 

Thanks!

Ian

 

Groups:

Comments

Stephen Edwards

Actually, the JFileChooser

Actually, the JFileChooser usage depends a lot on the situation.  The selectFileInChooser() and selectFilesInChooser() methods in the GUITestCase class are provided specifically for testing code that uses JFileChooser.

IIRC, the trick is to be sure that file choosers start out with the current working directory, or a subdirectory of it, as their point of focus when they are created. Those locations are all within the sandboxing scope of the program under test. You do this by providing a file (even just ".") to the chooser's constructor. A default JFileChooser will instead probably point to the home directory of the current user (or that user's "My Documents" directory under windows). The current user is determined by the effective uid of tomcat, which is probably a system account anyway. Such a home directory location is most likely outside the sandboxing area.

It is possible that the JavaTddPlugin should be resetting the user.home system properties during test runs, but it currently does not do this (although user.dir should be set correctly).

Ian Hickey

Thanks again for the reply.

I've found there is not too much of a learning curve getting the system fully functional. Java and Cpp plugins are now both happily testing student code (much to their initial chagrin ;) but eventual satisfaction.

 

Thanks,

Ian Hickey