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
+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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev