Skip to end of metadata
Go to start of metadata

Here's a bit of what I've found out while writing tests for Wicket. The code is using Wicket 1.2 beta 3, but most of it should apply to 1.1.1 as well.

  • To avoid code duplication, you can extend WicketTester to start in the application path you want through the WicketTester(String path) constructor. It might also be useful to add common initialization for all tests (like basic services and such) and provide an accessible method to add your standard authorization strategy for tests that need it (not all my tests do, in fact most don't). For instance:
  • Similarly, you may extend JUnit's testcase (when it makes sense) to instantiate your tester.
  • There are 2 things I usually test on a page: proper navigation and proper data binding. Data binding also includes correct data validation and error messaging. The following is an easy way to test the result of attribute modifiers (see also the mailing for few pointers to the source code of AjaxResponseTarget.respondComponent() as an example):
  • For data binding tests, I usually separate them in 2 parts:
    • Data->HTML (rendering): for this test, set your data on the database (through your services if you can) or pass it in the constructor of your class, then check if the correct components were generated and the data was correctly bound to the models of those components (when applicable. For instance:
    • HTML->Data (form submitting): this test verifies that the data you set on the form components gets sent to the correct data objects, and that the correct data validation and type conversion gets done. The code for those tests is typically centered around the FormTester. Below is an example of it:
  • For navigation tests, in most cases you can use the assertRenderedPage(Class) method. You can follow links by submitting the forms or clicking the link. Below are a couple of examples:
  • A few random testing tips:
    • Code reuse is important, but test code clarity is essential. No one tests for tests, so if tests are too complex due to heavy inheritance or intricate execution paths, they will contain bugs themselves, defeating the purpose of testing in the first place.
    • Test execution time is important too, if tests take 20 minutes to run you won't run them often (if ever). Try to avoid tests that rely heavily on the database, or create mock objects for the services those rely on.
    • In my code, most pages have package (default) scope. This decreases the apparent complexity of the system (you only need to know a few pages at a time), decreases coupling and makes the packages more cohesive. However, Wicket's relatively heavy use of reflection will cause runtime exceptions sometimes. Just be sure to touch all pages/panels during tests (unit tests AND manual tests).
  • No labels