WIP: Google Test Framework for Unit Testing BOINC #2443
Conversation
The client shows what kind of operating system it has detected in startup log message and elsewhere. This is confusing and not helping in troubleshooting when people expect these messages to describe the client itself. Change the messages to use client's build platform instead. Startup log message, output of --version and user agent string should be safe to change without breaking anything. The client still uses OS platform in various places but changing these would break stuff: - Scheduler request XML. Scheduler expects scheduler_request.platform_name to be OS primary platform. - client_state.xml. Client writes OS primary platform and alt platforms separately to client_state.xml. The client reads primary platform only to see if it has changed. The client doesn't read alt platforms but some other program might and depends on the platforms being as they are now. Not changing this means the client won't be able to detect when its own platform has changed. OS platform changes are still detected. - get_state GUI RPC. The client writes primary platform to client_state.platform_name and all platforms, including primary, to client_state.platform. BOINC Manager only reads client_state.platform. As such, client_state.platform_name could be changed to client's build platform but some 3rd party manager might depend on it being OS primary platform. - time_stats_log. The client writes platform info there. Unclear who uses that information. Closes BOINC#2386.
…e checked in to git.
…directory. test_url added with a simple check
Allow projects to show (non-DB) content even if stop_web is present (e.g. description of the project on front page). stop_web really means "the DB is offline".
client: show build not OS platform in messages
web: don't check for stop_web in page_head().
|
@AenBleidd @brevilo Can you guys take a look at this proposal as I think both of you have shown interest in adding automated testing to the BOINC framework. |
|
Hopefully next week... |
|
I'll try to take a look this weekend, Maybe also will prepare some changes to Travis to run these tests. |
|
I briefly looked at the implementation and it seems sound. I also looked into integrating this with travis which seems trivial although you should make the googletest install path configurable so we can put it in the travis cache under Getting coverage reports seems to be a bit more difficult as this involves running the compiled boinc binaries in the VM (I think). I haven't figured out how that works. A good service to use would be https://coveralls.io/ which has a github and Travis-CI integration. |
|
Follow up after I tested this locally in no particular order :
|
This is not intended to go into main source repo!
|
I already did part of the above steps in a (hasty) commit and will open a PR to see if it works. |
This is needed becaue of the way caching works. Needs to be improved since it builds wxWidgets when it is not needed.
|
Final note: travis integration is working but needs some final adjustements to keep the cache small. See #2457 |
|
I did some more testing and found a way to upload coverage reports to https://codecov.io. |
|
Christian, thanks for taking a look at this. I haven't had a chance to view it this weekend. But I will tomorrow. Thanks again. |
I believe the clean target for boinc needs to delete the gcov files too.
|
Does anyone have experience turning the example Makefiles.gtest to actually work with configure that BOINC uses for all the other folders? I was hoping someone with more experience in that would be able to help with that part. |
|
@ChristianBeer Would you consider the code coverage part of your comments to be a secondary or follow up to the google testing framework? Reason I ask is that I would like to get the google testing going first without adding additional requirements like additional tools. Thoughts? Thanks, |
|
As it turned out the code coverage part didn't involve additional requirements other than the codecov.io account. Integrating code coverage consists of only two changes. Adding the Converting the fixed Makefiles to autogenerated makefiles is not that difficult I think. The tricky part is to detect the presence of the googletest library and finding the needed include path. If that fails we could place a preconfigured |
|
@Uplinger So what's the plan now?
My personal opinion is to go with the second option and use a fixed path to googletest. Dealing with automake and autoconf is a fight that might not be worth fighting. In the long term I see BOINC moving to cmake so I rather don't want to put much effort into expanding the current autotools build files. |
Please ensure that any interaction with 3rd-party services uses an opt-in process. We'd like to be able to build and test BOINC without 3rd-party involvement or even an internet connection. Thanks! |
|
I read the proposal and I like it (well, standard unit testing, right?). My only comment from the one above is that you shouldn't make any assumption on where |
The generation and upload of coverage reports only applies to the Travis CI build. Users building and executing the test cases at home will not not be bothered with this. The only requirement is downloading the googletest library to the local system before building. |
|
I'll try to find some time this weekend to look into changing the autotools files to support |
|
I gave it a try and ended up with this branch: https://github.com/BOINC/boinc/commits/cb_gtest_framework which can build, install and detect googletest. It uses some outdated automake scripts that still seem to work. The last thing to do is write some new What about using cmake for the unit testing stuff and have a kind of hybrid setup? |
|
What is that status of this PR? There has been no progress for nearly one year. |
|
This is the first version of #2457 so it can be closed and the other should be reopened. |
Greetings,
I would like to get some feedback from the community about this approach to doing Unit Testing against the BOINC source code.
I have documented the design and initial thoughts here: https://github.com/Uplinger/boinc/wiki/BOINC-Google-Test-Design
The Code in this pull request reflect what is mentioned in the wiki page and gives people a chance to test it out for themselves.
Thanks,
-Keith Uplinger