You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Bill Dudney <bd...@mac.com> on 2005/07/12 16:35:37 UTC
[proposal] unit testing
Hi All,
I've just committed a couple of unit tests to the api subproject. I
will start adding a testing target to the build file later today but
I wanted to get this out there before anything else came up on my day
job.
I'd like to propose that we put any simple JUnit tests into the
following naming structure
${subproject.name}/tests/java/${pakcage.name}/${class.name}Test.java
subproject.name => the subproject (i.e. api, shared, etc)
package.name => the package where the class being tested resides
class.name => the name of the class being tested
Thoughts?
Also, I'd like to add running the unit tests and creating a report of
pass/fail to the 'dist' target so that the tests get run on every
'dist', thoughts? At some point Sean I'd also like to add the report
to the nightly build process, but we can talk about that in another
thread.
For cactus tests and web tests I'll do some experimenting and make
another proposal for those.
Looking forward to your feedback.
TTFN,
-bd-
Re: [proposal] unit testing
Posted by Sean Schofield <se...@gmail.com>.
> Sean, when I check in my build.xml file from the api/build directory
> I should delete the copies I made in the other subrpojects and update
> correct? (still trying to get the hang of the externals stuff).
If you modified the one in api/build copy it to current/build. Revert
the one in api/build. Commit the one in current/build and update
current.
That should do it.
> -bd-
sean
Re: [proposal] unit testing
Posted by Bill Dudney <bd...@mac.com>.
Ok, Sorry about the confusion, Eclipse was telling me that I checked
it in but the code had not been checked in.
Anyway I've made changes to the build.xml file and build.properties
in the various subprojects and added a src/test directory to each
subproj that should have one IMO.
I have a couple of tests done for API. The interesting one is the
FactoryFinderTest which actually had to do some tricks to effectively
test the FactoryFinder class so check that out if you have any
questions and/or feedback feel free.
I have tested ant dist-all in the top level build directory as well
as ant unit-test-all there. And run ant unit-test in each of the
subprojects. Everything appears to be working. There are probably
lurking wierdnesses since the only subproj with tests is api but its
at least a start.
Sean, when I check in my build.xml file from the api/build directory
I should delete the copies I made in the other subrpojects and update
correct? (still trying to get the hang of the externals stuff).
Thanks,
-bd-
On Jul 12, 2005, at 12:56 PM, Sean Schofield wrote:
> I still don't understand what you're talking about. I don't see a
> tests/java dir in mfaces/api. Are you sure you checked that in? (I
> didn't see anything in the svn mail either.)
>
> sean
>
> On 7/12/05, Bill Dudney <bd...@mac.com> wrote:
>
>> The trick is renaming the directory from tests/java to src/tests. The
>> first cut is checked into the api subrpoject, I'll rename though.
>>
>> TTFN,
>>
>> -bd-
>> On Jul 12, 2005, at 10:41 AM, Sean Schofield wrote:
>>
>>
>>>> This sounds fine to me. svn mv should do the trick correct?
>>>>
>>>>
>>>
>>> What trick? Do you have stuff already checked in or is the legacy
>>> stuff in the "before_svn_reorg"?
>>>
>>> sean
>>>
>>>
>>
>>
>
Re: [proposal] unit testing
Posted by Sean Schofield <se...@gmail.com>.
I still don't understand what you're talking about. I don't see a
tests/java dir in mfaces/api. Are you sure you checked that in? (I
didn't see anything in the svn mail either.)
sean
On 7/12/05, Bill Dudney <bd...@mac.com> wrote:
> The trick is renaming the directory from tests/java to src/tests. The
> first cut is checked into the api subrpoject, I'll rename though.
>
> TTFN,
>
> -bd-
> On Jul 12, 2005, at 10:41 AM, Sean Schofield wrote:
>
> >> This sounds fine to me. svn mv should do the trick correct?
> >>
> >
> > What trick? Do you have stuff already checked in or is the legacy
> > stuff in the "before_svn_reorg"?
> >
> > sean
> >
>
>
Re: [proposal] unit testing
Posted by Bill Dudney <bd...@mac.com>.
The trick is renaming the directory from tests/java to src/tests. The
first cut is checked into the api subrpoject, I'll rename though.
TTFN,
-bd-
On Jul 12, 2005, at 10:41 AM, Sean Schofield wrote:
>> This sounds fine to me. svn mv should do the trick correct?
>>
>
> What trick? Do you have stuff already checked in or is the legacy
> stuff in the "before_svn_reorg"?
>
> sean
>
Re: [proposal] unit testing
Posted by Sean Schofield <se...@gmail.com>.
> This sounds fine to me. svn mv should do the trick correct?
What trick? Do you have stuff already checked in or is the legacy
stuff in the "before_svn_reorg"?
sean
Re: [proposal] unit testing
Posted by Bill Dudney <bd...@mac.com>.
Hi Sean,
On Jul 12, 2005, at 9:23 AM, Sean Schofield wrote:
>> Hi All,
>>
>> I've just committed a couple of unit tests to the api subproject. I
>> will start adding a testing target to the build file later today but
>> I wanted to get this out there before anything else came up on my day
>> job.
>>
>
> Sounds good. You're going to add a test-all and test? Something
> like that?
>
Yep, test-all will run all the test targets for each subproject.
>
>> I'd like to propose that we put any simple JUnit tests into the
>> following naming structure
>>
>> ${subproject.name}/tests/java/${pakcage.name}/${class.name}Test.java
>>
>> subproject.name => the subproject (i.e. api, shared, etc)
>> package.name => the package where the class being tested resides
>> class.name => the name of the class being tested
>>
>> Thoughts?
>>
>
> Thanks for taking the initiative on the testing. I am in favor of a
> slightly different naming structure:
>
> ${subproject.name}/src/test/${pakcage.name}/${class.name}Test.java
>
> That was what I was thinking when I set up src/java in the directories
> (that we would eventually have src/test.) I believe this is also the
> convention followed in many other ASF projects including Struts.
>
This sounds fine to me. svn mv should do the trick correct?
>
>> Also, I'd like to add running the unit tests and creating a report of
>> pass/fail to the 'dist' target so that the tests get run on every
>> 'dist', thoughts? At some point Sean I'd also like to add the report
>> to the nightly build process, but we can talk about that in another
>> thread.
>>
>
> I'm thinking we might want to leave it out of dist but add it to
> nightly and release (in bootstrap.xml) Lets hold off on this part
> until you're done with the test targets and I'm done with bootstrap
>
> Generating and publishing a report as part of the nightly build
> would be cool.
>
Sounds fine, the report is easy to generate then its just a matter of
ftp'ing it to myfaces.apache.org/testresults or something like that.
>
>> For cactus tests and web tests I'll do some experimenting and make
>> another proposal for those.
>>
>
> Looking forward to that as well. I think you have the right idea
> concentrating on the stand-alone junit stuff first.
>
>
>> -bd-
>>
>
> sean
>
Re: [proposal] unit testing
Posted by Sean Schofield <se...@gmail.com>.
> Hi All,
>
> I've just committed a couple of unit tests to the api subproject. I
> will start adding a testing target to the build file later today but
> I wanted to get this out there before anything else came up on my day
> job.
Sounds good. You're going to add a test-all and test? Something like that?
> I'd like to propose that we put any simple JUnit tests into the
> following naming structure
>
> ${subproject.name}/tests/java/${pakcage.name}/${class.name}Test.java
>
> subproject.name => the subproject (i.e. api, shared, etc)
> package.name => the package where the class being tested resides
> class.name => the name of the class being tested
>
> Thoughts?
Thanks for taking the initiative on the testing. I am in favor of a
slightly different naming structure:
${subproject.name}/src/test/${pakcage.name}/${class.name}Test.java
That was what I was thinking when I set up src/java in the directories
(that we would eventually have src/test.) I believe this is also the
convention followed in many other ASF projects including Struts.
> Also, I'd like to add running the unit tests and creating a report of
> pass/fail to the 'dist' target so that the tests get run on every
> 'dist', thoughts? At some point Sean I'd also like to add the report
> to the nightly build process, but we can talk about that in another
> thread.
I'm thinking we might want to leave it out of dist but add it to
nightly and release (in bootstrap.xml) Lets hold off on this part
until you're done with the test targets and I'm done with bootstrap
Generating and publishing a report as part of the nightly build would be cool.
> For cactus tests and web tests I'll do some experimenting and make
> another proposal for those.
Looking forward to that as well. I think you have the right idea
concentrating on the stand-alone junit stuff first.
> -bd-
sean
Re: [proposal] unit testing
Posted by Bill Dudney <bd...@mac.com>.
Thanks Grant,
On Jul 12, 2005, at 9:33 AM, Grant Smith wrote:
> Bill,
>
> This is great, thanks for your efforts with this! I have a few
> comments.
>
> 1. Do we need /java/ in the test path structure?
Not really, Sean made an alternative suggestion and that is fine with
me. Just wanted to get something out there to get us started.
> 2. I don't think the tests should run as part of dist, but I do
> think they should run as part of the nightlies, and viewable as a
> daily report. Why ? Beacause we will eventually have hundreds of
> tests, that the Average Joe user doesn't care about and probably
> doesnt want slowing down the build.
Agreed on the nightly report. I was thinking dist so we could have
some sort of criteria like 95% pass before a release. But not married
to that either, easy enough to do 'ant test-all dist'.
> 3. I think the cactus tests should reside in the same path
> structure, or very near so that we don't clutter things up too much.
>
Agreed. I want to get the junit stuff done then start thinking
through the cactus. We have to build a war and deploy it to get
cactus tests to run so it won't make sense to have cactus tests in
each subproject (perhaps just impl & tomahawk). Tomcat and Weblogic
have ant tasks that will deploy a war, not sure about the rest of the
supported platforms but my end goal is to get cactus tests that we
can deploy to all the supported platforms and run the test to make
sure we have not broken compatibility. I'll make sure to be posting
regular updates.
TTFN,
-bd-
> Bill Dudney wrote:
>
>
>> Hi All,
>>
>> I've just committed a couple of unit tests to the api subproject.
>> I will start adding a testing target to the build file later
>> today but I wanted to get this out there before anything else
>> came up on my day job.
>>
>> I'd like to propose that we put any simple JUnit tests into the
>> following naming structure
>>
>> ${subproject.name}/tests/java/${pakcage.name}/${class.name}Test.java
>>
>> subproject.name => the subproject (i.e. api, shared, etc)
>> package.name => the package where the class being tested resides
>> class.name => the name of the class being tested
>>
>> Thoughts?
>>
>> Also, I'd like to add running the unit tests and creating a report
>> of pass/fail to the 'dist' target so that the tests get run on
>> every 'dist', thoughts? At some point Sean I'd also like to add
>> the report to the nightly build process, but we can talk about
>> that in another thread.
>>
>> For cactus tests and web tests I'll do some experimenting and
>> make another proposal for those.
>>
>> Looking forward to your feedback.
>>
>> TTFN,
>>
>> -bd-
>>
>>
>>
>
>
Re: [proposal] unit testing
Posted by Grant Smith <gr...@marathon-man.com>.
Bill,
This is great, thanks for your efforts with this! I have a few comments.
1. Do we need /java/ in the test path structure?
2. I don't think the tests should run as part of dist, but I do think
they should run as part of the nightlies, and viewable as a daily
report. Why ? Beacause we will eventually have hundreds of tests, that
the Average Joe user doesn't care about and probably doesnt want slowing
down the build.
3. I think the cactus tests should reside in the same path structure, or
very near so that we don't clutter things up too much.
Bill Dudney wrote:
> Hi All,
>
> I've just committed a couple of unit tests to the api subproject. I
> will start adding a testing target to the build file later today but
> I wanted to get this out there before anything else came up on my day
> job.
>
> I'd like to propose that we put any simple JUnit tests into the
> following naming structure
>
> ${subproject.name}/tests/java/${pakcage.name}/${class.name}Test.java
>
> subproject.name => the subproject (i.e. api, shared, etc)
> package.name => the package where the class being tested resides
> class.name => the name of the class being tested
>
> Thoughts?
>
> Also, I'd like to add running the unit tests and creating a report of
> pass/fail to the 'dist' target so that the tests get run on every
> 'dist', thoughts? At some point Sean I'd also like to add the report
> to the nightly build process, but we can talk about that in another
> thread.
>
> For cactus tests and web tests I'll do some experimenting and make
> another proposal for those.
>
> Looking forward to your feedback.
>
> TTFN,
>
> -bd-
>
>