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