Hi! >> > * "compressing" code by use of ids matching property names combined >> > with CompoundPropertyModel and/or PropertyListView >> >> Oh.. that will lead to fragility. > > It can, but in my experience it hasn't. Our domain objects rarely > change, and if they do, our unit tests catch that immediately.
It will bias towards not refactoring domain objects and it migh require thorough coverage of junit tests (... which is good). > The page doesn't even render if the property model doesn't work, so if you > have > a simple "tester.startPage(MyPage.class);" you're safe enough in most > cases. That's a smoke test, but you might need to see the page in various states (repeaters, popups, etc.). > - Unit test everything you can using WicketTester. It doesn't do > everything, but it's invaluable as a smoke test at the very least. If > possible, try and check stuff like visibility and enabled state of > your components too. I agree. But the more thorough your tests are the more covered you are, though the more costly it is and more costly to make changes. For example we have lots of prototype/beta user interfaces and it simply isn't practical to make thorough junit tests for all and we refactor a lot so compounds are not an option. ** Martin > > Carl-Eric > www.wicketbuch.de > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
