> Hi all,
>
> If you decide to rewrite XDoclet please consider a strategy for
> incorporating unit tests from the beginning. I much too often ran into
You bet! We should test at various levels:
1) Test that the classes in the core and the plugins *function* the way we
expect:
--> Plain JUnit
2) Test that the code generated by the plugins *look* the way we expect:
--> XMLUnit (for generated XML) and ???Unit for generated java sources.
This ???Unit could maybe be based on XJavadoc or QDox? -For comparing
source code I mean. Anyone wants to make this?
3) Test that the code generated by the plugins *work* the way we expect:
--> Cactus/StrutsTestCase/HttpUnit... on various containers
We'll use Clover or Quilt so we can keep track of how much we actually test.
Any other tips on the test strategy?
Aslak
> situations where parts of XDoclet didn't work any longer as expected
> after checking out the latest stuff from CVS. It really bugged me up to
> the point where I started writing some of the previously generated stuff
> manually.
>
> Httpunit, also on Sourceforge, is one of the best examples of how the
> use of JUnit can be used to guarantee quality. I'm open to questions,
> too.
>
>
> Just my $0.02, tom
> --
> thomas quas | "The truth indeed has never been preached by
> the Buddha,
> [EMAIL PROTECTED] | seeing that one has to realize it within oneself."
> | -- Lamkara Sutra --
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Xdoclet-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
