On Mar 30, 2011, at 11:45 AM, Muslim Chochlov wrote: > Hello John, Christian, > > I came up with some assessments regarding the project. > More in detail: > - Different measurement tools calculate about 16-17k lines of code in libqof > module. > - Number of unique functions is ~800 and ~ 500 of them are public, that is > available to other packages. > - Based on that and complexity measures it's possible to estimate time > required. It's feasible to accomplish this feature only for libqof module in > a duration of GSoC. (I'm in a process of writing proposal right now, where > everything would be explained in more detail) > > I hoped you could help me with: > - Defining the clear project goal. Currently I see it as - providing libqof > module with unit tests (coverage of 100%) (Creating UML diagrams? Do I have > to do refactoring on the fly as well? Or it's out of scope) > - If libqof is currently depending only on one system library it shouldn't > require any mocking and the process of writing unit tests should be kind of > straightforward. Also the priority and order in which I implement UT > shouldn't have any impact. Or do I miss something here? >
Muslim, Your assessment is fine. If getting LibQof fully tested is what you think you can get done in the scope of GSoC, then that's the right target. After all, at this point you're the only one here who knows how fast you can work, and frankly you're probably understimating the complexity. While a lot of those functions are simple setters and getters, there are also functions that are over 100 lines long and will need many tests run many times to fully exercise the different paths. Some of those will need to be refactored in order to get at the intermediate results for good testing. There are also interfaces (e.g., Backend) which will need mocks to exercise the paths in the interfaced code, and I expect that you'll want to mock parts of Qof itself while testing other parts to keep complexity under control. It's plenty of work to get done in ~90 days. I'm making good progress on the Gir2Umi program, so I hope to have a skeleton UML model in another week or so. Once we have that we can assess how much hand-modelling we need to do. There's no real priority within LibQof. It's at the middle of Gnucash and in the way of some important changes that we need to make, and we need to be sure that we don't break anything when we make those changes. That's what the tests are for. It seems to me that that should make a pretty clear goal for your application, too. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
