Hi,

Is there a good reason why almost all pig tests live in org.apache.pig.test
and not in the package of the class they're testing? This approach means
that many methods need to be made public just for testing instead of
package private. It also makes it harder to find tests in a package with
212 classes in it.

What would people feel about changing this standard to put test classes in
the package name of the class you're testing? It would be great to move
classes to new packages, but then there's that whole breaking patches
part...

thanks,
Bill

I'd like to but it's a huge project. We need to figure out what each
test is doing and put them in the right package. We need to
split/merge lots of test, also there are many tests cross packages, we
need to figure a way to deal with it.

Daniel

On Tue, Mar 27, 2012 at 11:33 AM, Bill Graham <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there a good reason why almost all pig tests live in org.apache.pig.test
> and not in the package of the class they're testing? This approach means
> that many methods need to be made public just for testing instead of
> package private. It also makes it harder to find tests in a package with
> 212 classes in it.
>
> What would people feel about changing this standard to put test classes in
> the package name of the class you're testing? It would be great to move
> classes to new packages, but then there's that whole breaking patches
> part...
>
> thanks,
> Bill

Backwards compatibility is really important for patches etc, but I would
like to set a line in the sand (even far out), where we give people a ton
of headway, and then we allow ourselves to make big structural changes that
break patch compatibility.

Big ones:
- Clean up formatting in files
- Change the test structure
- Change the source structure (going to happen with mavenization anyway, I
assume).

I'm sure there are other things like that. We could say "in 1 year, this
will happen" or whatever, and for a couple months we could rebase patches
against both to make it easier or something.

2012/3/27 Daniel Dai <[EMAIL PROTECTED]>

> I'd like to but it's a huge project. We need to figure out what each
> test is doing and put them in the right package. We need to
> split/merge lots of test, also there are many tests cross packages, we
> need to figure a way to deal with it.
>
> Daniel
>
> On Tue, Mar 27, 2012 at 11:33 AM, Bill Graham <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > Is there a good reason why almost all pig tests live in
> org.apache.pig.test
> > and not in the package of the class they're testing? This approach means
> > that many methods need to be made public just for testing instead of
> > package private. It also makes it harder to find tests in a package with
> > 212 classes in it.
> >
> > What would people feel about changing this standard to put test classes
> in
> > the package name of the class you're testing? It would be great to move
> > classes to new packages, but then there's that whole breaking patches
> > part...
> >
> > thanks,
> > Bill
>

I totally support this proposal.
Testing is one of those areas where Pig does not shine.
Cleaning up the mess there is definitely something I would like to see.

Also, many tests have been replaced by e2e tests, haven't they?

Cheers,
--
Gianmarco

On Tue, Mar 27, 2012 at 20:55, Jonathan Coveney <[EMAIL PROTECTED]> wrote:

> Backwards compatibility is really important for patches etc, but I would
> like to set a line in the sand (even far out), where we give people a ton
> of headway, and then we allow ourselves to make big structural changes that
> break patch compatibility.
>
> Big ones:
> - Clean up formatting in files
> - Change the test structure
> - Change the source structure (going to happen with mavenization anyway, I
> assume).
>
> I'm sure there are other things like that. We could say "in 1 year, this
> will happen" or whatever, and for a couple months we could rebase patches
> against both to make it easier or something.
>
> 2012/3/27 Daniel Dai <[EMAIL PROTECTED]>
>
> > I'd like to but it's a huge project. We need to figure out what each
> > test is doing and put them in the right package. We need to
> > split/merge lots of test, also there are many tests cross packages, we
> > need to figure a way to deal with it.
> >
> > Daniel
> >
> > On Tue, Mar 27, 2012 at 11:33 AM, Bill Graham <[EMAIL PROTECTED]>
> > wrote:
> > > Hi,
> > >
> > > Is there a good reason why almost all pig tests live in
> > org.apache.pig.test
> > > and not in the package of the class they're testing? This approach
> means
> > > that many methods need to be made public just for testing instead of
> > > package private. It also makes it harder to find tests in a package
> with
> > > 212 classes in it.
> > >
> > > What would people feel about changing this standard to put test classes
> > in
> > > the package name of the class you're testing? It would be great to move
> > > classes to new packages, but then there's that whole breaking patches
> > > part...
> > >
> > > thanks,
> > > Bill
> >
>

Going forward we should at least enforce that new test classes are added to
the package that they test against. Let's not let the problem compound by
adding to o.a.p.test.

On Wed, Mar 28, 2012 at 7:00 AM, Gianmarco De Francisci Morales <
[EMAIL PROTECTED]> wrote:

> I totally support this proposal.
> Testing is one of those areas where Pig does not shine.
> Cleaning up the mess there is definitely something I would like to see.
>
> Also, many tests have been replaced by e2e tests, haven't they?
>
> Cheers,
> --
> Gianmarco
>
>
>
> On Tue, Mar 27, 2012 at 20:55, Jonathan Coveney <[EMAIL PROTECTED]>
> wrote:
>
> > Backwards compatibility is really important for patches etc, but I would
> > like to set a line in the sand (even far out), where we give people a ton
> > of headway, and then we allow ourselves to make big structural changes
> that
> > break patch compatibility.
> >
> > Big ones:
> > - Clean up formatting in files
> > - Change the test structure
> > - Change the source structure (going to happen with mavenization anyway,
> I
> > assume).
> >
> > I'm sure there are other things like that. We could say "in 1 year, this
> > will happen" or whatever, and for a couple months we could rebase patches
> > against both to make it easier or something.
> >
> > 2012/3/27 Daniel Dai <[EMAIL PROTECTED]>
> >
> > > I'd like to but it's a huge project. We need to figure out what each
> > > test is doing and put them in the right package. We need to
> > > split/merge lots of test, also there are many tests cross packages, we
> > > need to figure a way to deal with it.
> > >
> > > Daniel
> > >
> > > On Tue, Mar 27, 2012 at 11:33 AM, Bill Graham <[EMAIL PROTECTED]>
> > > wrote:
> > > > Hi,
> > > >
> > > > Is there a good reason why almost all pig tests live in
> > > org.apache.pig.test
> > > > and not in the package of the class they're testing? This approach
> > means
> > > > that many methods need to be made public just for testing instead of
> > > > package private. It also makes it harder to find tests in a package
> > with
> > > > 212 classes in it.
> > > >
> > > > What would people feel about changing this standard to put test
> classes
> > > in
> > > > the package name of the class you're testing? It would be great to
> move
> > > > classes to new packages, but then there's that whole breaking patches
> > > > part...
> > > >
> > > > thanks,
> > > > Bill
> > >
> >
>

--
*Note that I'm no longer using my Yahoo! email address. Please email me at
[EMAIL PROTECTED] going forward.*

+1, though it might be necessary to document that somewhere on the site to
avoid confusion

2012/3/28 Bill Graham <[EMAIL PROTECTED]>

> Going forward we should at least enforce that new test classes are added to
> the package that they test against. Let's not let the problem compound by
> adding to o.a.p.test.
>
> On Wed, Mar 28, 2012 at 7:00 AM, Gianmarco De Francisci Morales <
> [EMAIL PROTECTED]> wrote:
>
> > I totally support this proposal.
> > Testing is one of those areas where Pig does not shine.
> > Cleaning up the mess there is definitely something I would like to see.
> >
> > Also, many tests have been replaced by e2e tests, haven't they?
> >
> > Cheers,
> > --
> > Gianmarco
> >
> >
> >
> > On Tue, Mar 27, 2012 at 20:55, Jonathan Coveney <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Backwards compatibility is really important for patches etc, but I
> would
> > > like to set a line in the sand (even far out), where we give people a
> ton
> > > of headway, and then we allow ourselves to make big structural changes
> > that
> > > break patch compatibility.
> > >
> > > Big ones:
> > > - Clean up formatting in files
> > > - Change the test structure
> > > - Change the source structure (going to happen with mavenization
> anyway,
> > I
> > > assume).
> > >
> > > I'm sure there are other things like that. We could say "in 1 year,
> this
> > > will happen" or whatever, and for a couple months we could rebase
> patches
> > > against both to make it easier or something.
> > >
> > > 2012/3/27 Daniel Dai <[EMAIL PROTECTED]>
> > >
> > > > I'd like to but it's a huge project. We need to figure out what each
> > > > test is doing and put them in the right package. We need to
> > > > split/merge lots of test, also there are many tests cross packages,
> we
> > > > need to figure a way to deal with it.
> > > >
> > > > Daniel
> > > >
> > > > On Tue, Mar 27, 2012 at 11:33 AM, Bill Graham <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > Is there a good reason why almost all pig tests live in
> > > > org.apache.pig.test
> > > > > and not in the package of the class they're testing? This approach
> > > means
> > > > > that many methods need to be made public just for testing instead
> of
> > > > > package private. It also makes it harder to find tests in a package
> > > with
> > > > > 212 classes in it.
> > > > >
> > > > > What would people feel about changing this standard to put test
> > classes
> > > > in
> > > > > the package name of the class you're testing? It would be great to
> > move
> > > > > classes to new packages, but then there's that whole breaking
> patches
> > > > > part...
> > > > >
> > > > > thanks,
> > > > > Bill
> > > >
> > >
> >
>
>
>
> --
> *Note that I'm no longer using my Yahoo! email address. Please email me at
> [EMAIL PROTECTED] going forward.*
>