You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by jo...@apache.org on 2005/05/12 03:58:14 UTC

cvs commit: ws-xmlrpc/src/test/org/apache/xmlrpc/test - New directory

jochen      2005/05/11 18:58:14

  ws-xmlrpc/src/test/org/apache/xmlrpc/test - New directory

Re: cvs commit: ws-xmlrpc/src/test/org/apache/xmlrpc/test - New directory

Posted by Jochen Wiedmann <jo...@gmail.com>.
Daniel L. Rall wrote:

> Is that package only for base test cases?  A good layout already exists
> today, where a parallel package hierarchy of unit tests exists in a
> separate tree on the file system.  Intermixing the unit tests in the
> same packages as the actual application code allows for testing of
> package private and protected members, which is key to full coverage for
> white-box testing.

I am in the process of rewriting the test suite from scratch for a new
branch, which I want to suggest as v3 in the near future. At that point,
I'll publish an overview, what has changed and what has not. I am quite
open for any suggestion. (Most probably, you and other people will want
to have changed a *real lot*, the package structure being the least
important part. May even be, that it is refused in entirety.)

Until then, please allow me to continue without considering these things
and have my own style of working. It allows me to get things done really
fast.


Jochen

P.S: I admit, though, that we seem to have different opinions on a "good
layout", given the fact, that org.apache.xmlrpc contains a real lot of
classes with *very* different topics.

Re: cvs commit: ws-xmlrpc/src/test/org/apache/xmlrpc/test - New directory

Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Thu, 2005-05-12 at 01:58 +0000, jochen@apache.org wrote:
> jochen      2005/05/11 18:58:14
> 
>   ws-xmlrpc/src/test/org/apache/xmlrpc/test - New directory

Is that package only for base test cases?  A good layout already exists
today, where a parallel package hierarchy of unit tests exists in a
separate tree on the file system.  Intermixing the unit tests in the
same packages as the actual application code allows for testing of
package private and protected members, which is key to full coverage for
white-box testing.