I don't see why some PigUnit lovin' is unreasonable. I'd love to see the patch (even in an unfinished state) to get a clearer idea of what your doing, but this sounds like a totally reasonable JIRA to me. I would love to see Pig+testing get more love, and this is a good first step. Right now testing both pig the project AND pig scripts is pretty rough going. But beyond that, whether or not it is a good fir for PigUnit's API is a separate question that can be hashed out in the JIRA...but at worst it could be put into a helper?
Documentation? Yes please. I'm a fan of the "you can never overdocument" philosophy. Of course, you CAN overdocument, but I don't know I've ever seen it actually happen and would love for Pig to have that problem? Definitely make some JIRAs, seems appropriate. Excited to have more people working on getting to contributing with Pig! Viva el cochino Jon 2012/5/10 Jeremy Hanna <[email protected]> > We've been using pig unit for a little while now and wanted to see if the > pig community would be okay with us posting a patch or two to add the > following: > > 1) add support to test multiple inputs and multiple outputs > One of our devs said - It has a really nice method assertOutput(String > inputAlias, String[] inputValues, String outputAlias, String[] > expectedOutputValues). That method lets you override an input alias > variable with a hardcoded list of values. That way, the script doesn't > actually have to read that input variable from hdfs or cassandra. Then, it > runs the script and checks the specified output alias variable against the > expected set of values. It's a really nice way to test your entire pig > script with a single method call, but only IF your script has exactly 1 > input and 1 output. If you want to test more complicated scripts, you have > to jump through some hoops in order to override more input variables. But, > it would be fairly easy to change PigUnit so that it can override any > number of inputs and check any number of outputs and do so easily. That's > basically the change that I put into the base testing class I wrote. But, > it would be better to push that into PigUnit itself, and it's something > that could easily be done in an afternoon. > > Does this sound reasonable and something we could hack on at our Austin > hack day tomorrow? > > 2) Some javadocs for the pig unit test classes to make them more readable. > > Would we just create a couple of tickets for this? Just trying to make > sure that's the route to take as we're trying to get bootstrapped on > helping out where we can. > > Thanks! > > Jeremy
