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 > > >
