[ http://issues.apache.org/jira/browse/COCOON-1779?page=all ]
Jorg Heymans reassigned COCOON-1779:
Assign To: Jorg Heymans
[PATCH] JUnit tests for LocaleAction
Key: COCOON-1779
URL: http
[
http://issues.apache.org/jira/browse/COCOON-1779?page=comments#action_12369977
]
Jorg Heymans commented on COCOON-1779:
--
Applied, thanks .
Please have a look if all went in ok and close this issue.
[PATCH] JUnit tests for LocaleAction
[
http://issues.apache.org/jira/browse/COCOON-1779?page=comments#action_12369978
]
Jorg Heymans commented on COCOON-1779:
--
Actually, could have a look in porting the patch to trunk ? mockrequest.diff
does not seem to apply there.
[PATCH] JUnit
[
http://issues.apache.org/jira/browse/COCOON-1779?page=comments#action_12369981
]
Jorg Heymans commented on COCOON-1779:
--
nevermind, my patching skills are getting rusty...
Synchronized to trunk, please check and close this issue.
[PATCH] JUnit
the reporter reopen it if
necessary.
[PATCH] JUnit tests for LocaleAction
Key: COCOON-1779
URL: http://issues.apache.org/jira/browse/COCOON-1779
Project: Cocoon
Type: Test
Components: * Cocoon Core
Versions: 2.1.9-dev
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Freitag, 26. August 2005 13:53
To: dev@cocoon.apache.org
Subject: Re: JUnit Tests and maven status
Le 26 août 05, à 13:17, Daniel Fagerstrom a écrit :
Bertrand Delacretaz wrote:
Maybe we could
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? If we just
to the trunk yet, but once this is done they
are plain JUnit tests, so I'm not sure if an anteater plugin is needed
for the trunk.
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
ones.
They haven't been ported to the trunk yet, but once this is done they
are plain JUnit tests, so I'm not sure if an anteater plugin is needed
for the trunk.
Ah, great - so no need for a plugin. Good!
When we have this we have to decide/plan how to continue from there. We
need a solution
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
Le 26 août 05, à 13:17, Daniel Fagerstrom a écrit :
Bertrand Delacretaz wrote:
Maybe we could dedicate the second day of the GT hackathon to this?
Dedicate is a little bit strong for my taste, I would like to see some
more work on the block stuff also.
Sure - I was more meaning form a
Daniel Fagerstrom wrote:
Also, it would be good if at least important bugs where documented in
terms of a failing unit test.
Yeah, that would be nice.
Failing tests that we don't care about anymore should be removed.
Failing tests of the kinds I described above makes a difference IMO.
Carsten Ziegeler wrote:
snip/
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.
When we have this we have to decide/plan how to continue from
Am So, den 04.07.2004 schrieb bernhard huber um 20:06:
hi,
i have committed some more junit tests for cocoon core components.
The committed junit tests are
* ParameterMatcher.java
* PreparableMatcher.java
* RegexpURIMatcher.java
* RequestAttributeMatcher.java
hi,
i have committed some more junit tests for cocoon core components.
The committed junit tests are
* ParameterMatcher.java
* PreparableMatcher.java
* RegexpURIMatcher.java
* RequestAttributeMatcher.java
* RequestParameterMatcher.java
* SessionAttributeMatcher.java
* WildcardURIMatcher.java
JUnit tests (ok, I admit this is a recent 'normal'; I've only recently seen the light). Where should I put my test classes? For example, I am creating an o.a.c.generation.MIDIGenerator, at moment. I have put my TestMIDIGenerator class into o.a.c.test.generation. Is that sensible? Do you have any
16 matches
Mail list logo