Hey, I guess KMPProjectBuilder could be hard to test without some refactoring. It takes care of converting the data which is loaded from the svn repository into a Kumpel model. This is a bit complicated. I will try to explain a bit in order to get you started: First the subversion data from the repository is loaded by using the external java library. This is done with the class KMPProjectLoader. After loading this creates a KMPProjectBuilder. In the build method the creation of the model is started in several steps. The first step is building the model for the first svn revision of which you build the model. This is done in the method createBaseDirectoryTree. A model of the entire directory tree of that revision is built for that revision. After that, it incrementally builds the rest of the model using the data of the following commits. This is done in buildFromLog. The SvnCommit and SvnChangedPath objects which are created by the log parser exactly represent the data from the svn commit log. They are used to build the kumpel model. For each revision, only the delta is modeled. This is a bit more complex than it sound. When a file or directory history is copied from another history (which also can be from outside of the current project you are loading), another KMPProjectBuilder is created which then loads this additional history (see buildAdditionalHistory). The information whether a history is a copy of another history is stored in SvnChangedPath copyFromPath. The next step is to cleanup the model. I can't remember much about this step, but it involves cleaning up duplicated file versions which can occur when directories are copied. After that, the file content diffs are parsed and assigned to the file versions in the model. This is done in parseInitialDiffs and parseRegularDiffs. Maybe these individual phases could be refactored so that they would be testable individually. It would be definitely be valuable to have at least one test which uses prefetched svn data and then builds a kumpel model using the builder just as a black box test. Testing the individual steps might be difficult at the moment, because the building process loads all data from the filesystem and each step depends on the previous steps. The model classes should be easy to test. I guess documenting the Builder would be a valuable thing as well. I could assist you with that. Feel free to ask any questions you have. I hope this helped a bit to clear things up. Cheers Matt 2011/12/28 Felipe González <felipegmch(a)gmail.com> Hi! I am Felipe González a student from Alexandre Bergel. I would like to understand Kumpel and improve it's overall quality. I will be fully working on it for the next two weeks. Here is what I can see in Kumpel: - There's no documentation in the classes nor the tests classes - Almost all test methods hasn't a proper method category - There's almost no class hierarchy - The next classes doesn't have any tests: KMPProjectBuilderConfig KMPProjectLoader KMPImportSVNCommand PPDateParser KMPFileVersion PPProjectInfoParser KMPProjectLoader KMPProjectBuilderConfig KMPProjectBuilder is the largest class, but it is almost not tested. I would like to improve the coverage of Kumpel. Does it makes sense for you to write tests for this class? Like this, I'll learn about Kumpel and hopefully be able to make a useful contribution :) I will put the result of my work in the repository ss3.gemstone.com/ss/CC6403-2011 I will let you know how it goes. Any suggestion? Regards, Felipe -- Felipe González Martínez Estudiante de Ingeniería Civil en Computación Departamento de Ciencias de la Computación Universidad de Chile _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev