Hello all, I noticed that most of our scaffold unit tests are kinda hard to maintain. specially because they compare XHTML as strings, instead of the structure as a whole. This implies that if you place a line break in a generated XHTML for example, it breaks the whole test as well. What about if we refactor these tests to use XmlUnit instead ? (http://xmlunit.sourceforge.net/) This way we could compare the structure without the ugly plain string comparison, WDYT ? Regards,, George Gastaldi _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Yeah, I'm not sure there's a great way around this aside from a more black-box functional approach, but even that might not be getting as fine-grained as some of these tests need to be. With greater test coverage, I think it could be replaced, however. ~Lincoln On Mon, Jun 11, 2012 at 10:25 PM, Richard Kennard < richard(a)kennardconsulting.com&gt; wrote: > +1 for this. > > However note there are different levels of tests. Classes like > FacesScaffoldScenarioTest are only meant to test very small, very specific > things. Basically > regression testing. Classes like FacesScaffoldWeatherTest are also small > and specific. > > The real testing is done using Arquillian (like > FacesScaffoldPetClinicClient and FacesScaffoldShoppingClient). Because > whilst your point about 'if you > place a line break in a generated XHTML... it breaks the whole test' is > very valid, even with XmlUnit you are vulnerable to 'if you place an extra > XML > element in a generated XHTML... it breaks the whole test'. > > Testing through Arquillian is the only way to be really sure the > generated app actually works, IMHO. Because you are testing it the way the > user would. > > However, definitely +1 for using XmlUnit, as far as that goes. > > Regards, > > Richard. > > On 12/06/2012 12:09 PM, George Gastaldi wrote: > > Hello all, > > > > I noticed that most of our scaffold unit tests are kinda hard to > > maintain. specially because they compare XHTML as strings, instead of > > the structure as a whole. > > This implies that if you place a line break in a generated XHTML for > > example, it breaks the whole test as well. > > What about if we refactor these tests to use XmlUnit instead ? > > (http://xmlunit.sourceforge.net/) > > This way we could compare the structure without the ugly plain string > > comparison, WDYT ? > > > > > > Regards,, > > George Gastaldi > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Ah! Whoops, yes, that is actually a very good idea :) Thanks Dan, it's late and I'm tired :p On Wed, Jun 13, 2012 at 1:12 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > Let's not miss the original point that George makes, which is that > comparing the structure may make less fragile tests than comparing the raw > HTML. I tend to agree, unless there is something very important about > maintaining the whitespace. Even then, a structure comparison tool should > be able to accommodate that rule. > > -Dan > > > On Wed, Jun 13, 2012 at 1:00 AM, Lincoln Baxter, III < > lincolnbaxter(a)gmail.com&gt; wrote: > >> Yeah, I'm not sure there's a great way around this aside from a more >> black-box functional approach, but even that might not be getting as >> fine-grained as some of these tests need to be. With greater test coverage, >> I think it could be replaced, however. >> >> ~Lincoln >> >> >> On Mon, Jun 11, 2012 at 10:25 PM, Richard Kennard < >> richard(a)kennardconsulting.com&gt; wrote: >> >>> +1 for this. >>> >>> However note there are different levels of tests. Classes like >>> FacesScaffoldScenarioTest are only meant to test very small, very specific >>> things. Basically >>> regression testing. Classes like FacesScaffoldWeatherTest are also >>> small and specific. >>> >>> The real testing is done using Arquillian (like >>> FacesScaffoldPetClinicClient and FacesScaffoldShoppingClient). Because >>> whilst your point about 'if you >>> place a line break in a generated XHTML... it breaks the whole test' is >>> very valid, even with XmlUnit you are vulnerable to 'if you place an extra >>> XML >>> element in a generated XHTML... it breaks the whole test'. >>> >>> Testing through Arquillian is the only way to be really sure the >>> generated app actually works, IMHO. Because you are testing it the way the >>> user would. >>> >>> However, definitely +1 for using XmlUnit, as far as that goes. >>> >>> Regards, >>> >>> Richard. >>> >>> On 12/06/2012 12:09 PM, George Gastaldi wrote: >>> > Hello all, >>> > >>> > I noticed that most of our scaffold unit tests are kinda hard to >>> > maintain. specially because they compare XHTML as strings, instead of >>> > the structure as a whole. >>> > This implies that if you place a line break in a generated XHTML for >>> > example, it breaks the whole test as well. >>> > What about if we refactor these tests to use XmlUnit instead ? >>> > (http://xmlunit.sourceforge.net/) >>> > This way we could compare the structure without the ugly plain string >>> > comparison, WDYT ? >>> > >>> > >>> > Regards,, >>> > George Gastaldi >>> > _______________________________________________ >>> > forge-dev mailing list >>> > forge-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/forge-dev >>> > >>> > >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://google.com/profiles/dan.j.allen > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better."

George's point is well taken. The current tests could be made less fragile. In particular, there have been a number of complaints about '\r\n versus \n' when building on Windows/Linux. I believe these are all resolved now, but the basic concept is sound. Having said that, there *is* something important about testing the white space. Namely, we are making sure the generated code is indented correctly (has the correct number of \t's) relative to its surrounding template. The idea is that it doesn't 'stick out' as being generated code. Also, with respect to 'black-box versus unit tests', I don't think this should be an either-or thing. I think we should have both. Regards, Richard. On 13/06/2012 3:12 PM, Dan Allen wrote: > Let's not miss the original point that George makes, which is that comparing the structure may make less fragile tests than comparing the raw HTML. I > tend to agree, unless there is something very important about maintaining the whitespace. Even then, a structure comparison tool should be able to > accommodate that rule. > > -Dan > > On Wed, Jun 13, 2012 at 1:00 AM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com>> wrote: > > Yeah, I'm not sure there's a great way around this aside from a more black-box functional approach, but even that might not be getting as > fine-grained as some of these tests need to be. With greater test coverage, I think it could be replaced, however. > > ~Lincoln > > > On Mon, Jun 11, 2012 at 10:25 PM, Richard Kennard < richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> wrote: > > +1 for this. > > However note there are different levels of tests. Classes like FacesScaffoldScenarioTest are only meant to test very small, very specific things. > Basically > regression testing. Classes like FacesScaffoldWeatherTest are also small and specific. > > The real testing is done using Arquillian (like FacesScaffoldPetClinicClient and FacesScaffoldShoppingClient). Because whilst your point about > 'if you > place a line break in a generated XHTML... it breaks the whole test' is very valid, even with XmlUnit you are vulnerable to 'if you place an > extra XML > element in a generated XHTML... it breaks the whole test'. > > Testing through Arquillian is the only way to be really sure the generated app actually works, IMHO. Because you are testing it the way the user > would. > > However, definitely +1 for using XmlUnit, as far as that goes. > > Regards, > > Richard. > > On 12/06/2012 12:09 PM, George Gastaldi wrote: > > Hello all, > > > > I noticed that most of our scaffold unit tests are kinda hard to > > maintain. specially because they compare XHTML as strings, instead of > > the structure as a whole. > > This implies that if you place a line break in a generated XHTML for > > example, it breaks the whole test as well. > > What about if we refactor these tests to use XmlUnit instead ? > > (http://xmlunit.sourceforge.net/) > > This way we could compare the structure without the ugly plain string > > comparison, WDYT ? > > > > > > Regards,, > > George Gastaldi > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://google.com/profiles/dan.j.allen > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

any reason why we don't just run something like jtidy on the generated output and thus does not have to care about indentation too much everywhere ? http://jtidy.sourceforge.net/ /max On 13 Jun 2012, at 07:41, Lincoln Baxter, III wrote: > Agreed on all counts. This is one case where formatting matters, because people are going to see and interact with this code, even though I'd argue they could just apply their own formatter, it's best if they be presented with something nice to begin with :) > > On Wed, Jun 13, 2012 at 1:19 AM, Richard Kennard <richard(a)kennardconsulting.com&gt; wrote: > George's point is well taken. The current tests could be made less fragile. In particular, there have been a number of complaints about '\r\n versus \n' > when building on Windows/Linux. I believe these are all resolved now, but the basic concept is sound. > > Having said that, there *is* something important about testing the white space. Namely, we are making sure the generated code is indented correctly (has > the correct number of \t's) relative to its surrounding template. The idea is that it doesn't 'stick out' as being generated code. > > Also, with respect to 'black-box versus unit tests', I don't think this should be an either-or thing. I think we should have both. > > Regards, > > Richard. > > On 13/06/2012 3:12 PM, Dan Allen wrote: >> Let's not miss the original point that George makes, which is that comparing the structure may make less fragile tests than comparing the raw HTML. I >> tend to agree, unless there is something very important about maintaining the whitespace. Even then, a structure comparison tool should be able to >> accommodate that rule. >> >> -Dan >> >> On Wed, Jun 13, 2012 at 1:00 AM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com>> wrote: >> >> Yeah, I'm not sure there's a great way around this aside from a more black-box functional approach, but even that might not be getting as >> fine-grained as some of these tests need to be. With greater test coverage, I think it could be replaced, however. >> >> ~Lincoln >> >> >> On Mon, Jun 11, 2012 at 10:25 PM, Richard Kennard <richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> wrote: >> >> +1 for this. >> >> However note there are different levels of tests. Classes like FacesScaffoldScenarioTest are only meant to test very small, very specific things. >> Basically >> regression testing. Classes like FacesScaffoldWeatherTest are also small and specific. >> >> The real testing is done using Arquillian (like FacesScaffoldPetClinicClient and FacesScaffoldShoppingClient). Because whilst your point about >> 'if you >> place a line break in a generated XHTML... it breaks the whole test' is very valid, even with XmlUnit you are vulnerable to 'if you place an >> extra XML >> element in a generated XHTML... it breaks the whole test'. >> >> Testing through Arquillian is the only way to be really sure the generated app actually works, IMHO. Because you are testing it the way the user >> would. >> >> However, definitely +1 for using XmlUnit, as far as that goes. >> >> Regards, >> >> Richard. >> >> On 12/06/2012 12:09 PM, George Gastaldi wrote: >> > Hello all, >> > >> > I noticed that most of our scaffold unit tests are kinda hard to >> > maintain. specially because they compare XHTML as strings, instead of >> > the structure as a whole. >> > This implies that if you place a line break in a generated XHTML for >> > example, it breaks the whole test as well. >> > What about if we refactor these tests to use XmlUnit instead ? >> > (http://xmlunit.sourceforge.net/) >> > This way we could compare the structure without the ugly plain string >> > comparison, WDYT ? >> > >> > >> > Regards,, >> > George Gastaldi >> > _______________________________________________ >> > forge-dev mailing list >> > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/forge-dev >> > >> > >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://google.com/profiles/dan.j.allen >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev