Carsten Ziegeler wrote:
Yesterday I ran our junit tests just to find out the some of the do not
succeed :( I fixed the ones in core, about from the virtual pipeline
generator test (as reported). There are still several tests failing in
the blocks.
Now, I'm wondering whats the use of failing test cases is?
In test driven program development you are supposed, IIRC, to specify
the intended functionality in terms of (initially failing) tests. Then
more and more and eventually all tests will succeed as you develop your
program.
I used failing tests in the template block (although not in a completely
systematic way), to remind myself and other developers about thing that
are supposed to work but not work yet. I haven't worked on the template
block for quite a while, so I don't know the current situation. Last
time I tried I think the same tests succeeded in the new JXTG as in the
original one. But there was one or two tests that failed on both and
that (possibly) indicated a regression from what is described in the
documentation and what worked once.
Also, it would be good if at least important bugs where "documented" in
terms of a failing unit test.
If we just
ignore failing test cases we can delete them right away. It doesn't make
any difference.
Failing tests that we don't care about anymore should be removed.
Failing tests of the kinds I described above makes a difference IMO.
So I think we should really start fixing them - if noone
has time, we should do it at the GT hackathon :)
Yes.
We have to fix them anyway because Maven will run them directly after
compilation before creating the jar and if the tests fail you don't get
a jar. (Of course you can tell Maven to skip tests or to ignore
errors/failures). So as soon as we are using Maven we will get annoyed
by failing test case very quickly.
This behaviour doesn't work that well with test driven programming and
"failing test as bug report". Is there a possibility to indicate that a
test should be runned, but that the jar should br cretated even if it fails?
Now, the actual migration to m2 is continuing very slowly. Actually we
have the initial configuration for maven to compile the core and build
the webapp just containing the core. Actually this was very easy.
Unfortunately there are some minor bugs in m2-alpha3 which makes it
impossible to use for us without restructuring a repository. The alpha3
version was not able to handle non java files in the src tree.
This is fixed in the current svn, but unfortunately :) the current svn
of m2 is not that stable, it has some other minor problems that have to
be fixed before we can use m2. But the maven community and especially
Brett is very helpful and we hope to have things sorted out by next week.
I'm trying to implement some things for m2 and plan to do a anteater
plugin (if that is not available yet).
I added some rather time consuming tests while developing VPCs and
sitemap blocks. These tests are not really unit tests but rather
functional tests. As soon as we have the HtmlUnit tests working in trunk
(and I find some time), I will port the sitemap level test stuff that I
developed to HtmlUnit.
So hopefully we have next week a version that compiles the core code,
runs the junit tests,(on successful testing) package this into the core
jar and builds the webapp with the core and all jars.
Great, thanks for your work on this.
When we have this we have to decide/plan how to continue from there. We
need a solution for several things, like how to deal with samples (how
can you exclude them etc.), how to deal with javadocs and so on.
Yes.
/Daniel
