Home
> Test Driven Development, Wicket > Writing readable and maintainable integration tests (not only) in Wicket
Writing readable and maintainable integration tests (not only) in Wicket
Post moved to http://www.paulszulc.com/2009/writing-readable-and-maintainable-integration-tests-not-only-in-wicket/
Categories: Test Driven Development, Wicket
testability, testable code, tests, Wicket, wickettester

Great article!
Couple of questions:
1) Any reason why you are using 3 helper classes instead of one?
2) Can you post an example of a helper class, and how to instantiate it? For example, you need the WicketTester for all three classes. So, the WicketTester is probably an argument of the constructor.
3) It looks like you only use 2 helper classes (and the WicketTester). Is this true?
Hi Mario,
1. the only reason to use 3 helper classes and not one, is maintainability. If I put all of those methods into one helper class, then after a while it would be quite difficult to search through it. The main purpose of those helper class is reusability. If some developer writes method clickLoginLink(), then I won’t have to. So I have one helper class for each common action, one for clicking links and buttons, one for form filling and one for entering the application. This helps me maintaining those helper methods. So for example if my test needs to fill some form with data, I first go directly to FormFiller to see whether other developer didn’t write appropriate method already.
2. I’m currently writing a post about test base template for Wicket testing, so stay tuned. The rule of thumb is to instantiate tester class and helper classes in init method (method annotated with @Before annotaion, if you are using JUNit).
3. in this example, yes. I didn’t show usage of FormFiller helper class.
mario,
you can find example of usage in this post http://paulszulc.wordpress.com/2009/08/17/wickettestbase-base-class-for-testing-wicket-spring-web-applications/
Thx, I will take a look at it.