Originally posted by J. B. Rainsberger:
Hello, authors.
First, congratulations on completing your book. I appreciate how much work you've put into it and I hope it's a tremendous success.
Thanks, so do we.
[qoute]
I have a question about Wicket and TDD/evolutionary design. I am a TDD practitioner and I get the best results when I let my designs evolve. What are three impediments--big or small--you think I would encounter if I test-drove a Wicket-based application? I ask because I frequently give a half-day tutorial on TDD and Enterprise Code, and I'd like to introduce some more modern frameworks, platforms and tools, and I'd like to know what I'm likely to encounter if I tried to introduce Wicket into the mix.
Manning has published a book on TDD called
Test Driven and its web testing chapter includes Wicket in a TDD way. I have the book since a week, but haven't gotten around to reading it.
WicketTester, though not perfect, allows you to test your panel or page in isolation without having to start up a whole application server. It will test the serverside logic, and you can test attributes of markup elements by parsing the dom. It won't catch browser errors though (unless you know them and write dom-tests for it).
I have little or no experience in TDD, though I like the idea. In practice I find it hard to sustain.
I definitely see value of TDD when building Wicket Panel's (reusable components that have their own markup). Anything larger (Pages) may become harder to test, because it typically needs to work on more data.
It is easy to test components in isolation. For example you could create tests for a MenuComponent, OrganizationDropDownChoice, etc. Testing a whole page would be more like functional testing I guess.
