Hmm, that doesn't sound right -- are you looking at this? https://hudson.apache.org/hudson/job/Mahout-Quality/clover/
This shows which packages are mostly un-tested and I don't believe it's any in .cf.taste. I think you're welcome to jump in anywhere you fancy. Example code does not need tests. There are lots of bits of code in mahout-math imported from Colt which were never further cleaned up or tested and are marked "@deprecated" as a result. I think any of those would be a good place to start, even though some of the bits are esoteric math and hard to perhaps understand. Sebastian has done a good job establishing a pattern for unit testing MapReduce jobs and that could be expanded to other MapReduce jobs. I don't think the recommender jobs need it and maybe others can volunteer candidates for testing. @dev now is probably a good time to talk about whether more of the deprecated, unused math code can be deleted. If nobody's touched it, nobody's bothered to test it, nobody's using it (and recall it is not to be used by external users as it is deprecated) -- would you want someone to bother writing tests? I feel like this code is just going to be there in the same state in another 12 months. It's not right to leave deprecated code indefinitely. What should we do then? On Thu, Dec 23, 2010 at 7:06 PM, Walter Gillett <[email protected]>wrote: > I'm interested in learning about and contributing to Mahout and seems to me > that > creating some unit tests would be a good place to start. Looking at the > code > coverage stats, appears that there's lots of work to do, e.g., there > appears to > be no coverage for the Taste module. Should I just pick something > random/interesting to start with, or is there some high-priority part of > the > code that you would recommend to work on? > > Walter Gillett > > > >
