Both solutions are not ideal, since we do not want our tests to become brittle. We want to functionally test components in multiple variants, but where the variants vary in mere layout (css classes), we do not want to have tests break just because the layout changes (as long as the component still functions).
Another solution for us would be to have components without variant loading fallback behavior. So in general it is obviously good if a component falls back to default markup, because we might have a component tree where only a subset of involved components have a variant markup. But for those component are supposed to have it, it would be good if they fail when it is not found (e.g. due to typos). However, I guess we cannot implement that logic inside getVariant(), as the child components will invoke it. Is there another hook we could use to fail for specific components when their variant was not found? On Mon, Sep 8, 2014 at 9:12 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi, > > There is nothing specific for this. > But you can use > various org.apache.wicket.util.tester.WicketTester#executeTest() methods to > check the response against a valid response pre-saved in a file. > Or you can use org.apache.wicket.util.tester.WicketTester#assertContains() > to check that a specific String (actually a Regex) is in the response. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > > On Fri, Sep 5, 2014 at 4:30 PM, Thibault Kruse <tibokr...@googlemail.com> > wrote: > >> Thanks Martin, >> >> that works for us. I missed that Variants are inherited from parents. >> >> Is there also a good way that I can assure in our unit tests that the >> variant markup for certain components exists and was found? Else a >> typo would go unnoticed in the unit tests. >> >> cheers, >> Thibault >> >> On Wed, Sep 3, 2014 at 12:59 PM, Martin Grigorov <mgrigo...@apache.org> >> wrote: >> > Hi, >> > >> > The behaviors are not used for variations. >> > For such use cases you should >> > override org.apache.wicket.Component#getVariation() on the (base) page. >> > This way all components will know the correct variation. >> > >> > Martin Grigorov >> > Wicket Training and Consulting >> > https://twitter.com/mtgrigorov >> > >> > >> > On Wed, Sep 3, 2014 at 1:09 PM, Thibault Kruse <tibokr...@googlemail.com >> > >> > wrote: >> > >> >> Hi, >> >> >> >> playing around with Variants for Components, I am wondering whether >> >> there is an elegant way to steer Variant markup loading via a >> >> Behavior. >> >> >> >> In our case we want to use a different markup layout based on the >> >> width of the container the component is going to be used in, visually. >> >> >> >> So if we imagine a Browser window with desktop size, we might want to >> >> use a component on the full width, on a third of the width, or a >> >> quarter of the width. >> >> >> >> For each such container width, we need different responsive design >> >> markup. Since this may affect many of our components which inherit >> >> from different wicket components, I'd like to just add another html >> >> markup file for the variant, and add a Behavior to the component that >> >> decides the Variant. >> >> >> >> cheers, >> >> Thibault >> >> >> >> --------------------------------------------------------------------- >> >> 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
