Thanks for the information Jon, sounds promising. If time permits I will have to dig deep and split all those test cases into separate files. -- Christoffer Holmstedt
2015-02-19 21:05 GMT+01:00 Jon A. Cruz <jon@...18...>:
On Wed, Feb 18, 2015, at 10:05 PM, Christoffer Holmstedt wrote:
It's within another project and I'm afraid I can't share any links to it as it is not an open project.
Great, you have good experience from gtest and you nailed it now as a general compilation/linking performance problem. The main problem in our current project is that it is only one main file which runs all tests but as you suggests I assume it is possible to split the test suites into multiple files and run only a small part of them when needed...and before committing you run them all. Though when searching gtest documentation I haven't found any "best practice" suggestion on how to structure the test suites into some kind of hierarchy. If you know how to do this properly and maybe know an open project which have a good structure tell me ;)
In the upcoming weeks I will set up two test branches to try out both Google test and Boost test (in separate branches) at the moment the current tests we have are written in cpptest (I think). When I get going I will send an email to the mailing list, but as I said above any help in advance on best practice is appreciated.
Normally one would want to break test sources up to have a .cpp per test case at most. If a project has good organization you might have one test .cpp per main source .cpp (as opposed to projects that randomly clump things into .cpp source files). Additionally common fixtures and other such helpers would be broken out into their own .h & .cpp files. All those things will help reduce incremental build times for the test executable.
So you would have foo.cpp hold the source for the class Foo. Then you would have foo-test.cpp that holds the tests that are associated with that class. They could hold one or more test "cases" that collect the individual tests. When working on foo.cpp you could run GTest with Foo.* if that matched your test case name. Then run with all before committing.
GTest really doesn't focus on hierarchy. So it doesn't do the same nested groups like Boost Test does with its suites.
And as far as breaking up the tests to separate executables goes (the other way to get organization), it might make sense if your project's code created more than one executable or library. Otherwise just splitting out from a single monolithic .cpp file should really help your build times.
-- Jon A. Cruz jon@...18...
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel