C++ Unit testing framework up and running
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- adrianinsaval
- Veteran
- Posts: 5548
- Joined: Thu Apr 05, 2018 5:15 pm
Re: C++ Unit testing framework up and running
I thought it wasn't necessary to compile and run the tests when packaging? As for adding stuff to the libpack, contact @uwestoehr
Re: C++ Unit testing framework up and running
Included in FC version is 1.12, but already available Release 1.13.0
And GoogleTest developers recommend:
1.35 sec
And GoogleTest developers recommend:
... updating to the latest commit in the main branch as often as possible.
Code: Select all
$ time git clone --depth 1 https://github.com/google/googletest
Cloning into 'googletest'...
remote: Enumerating objects: 274, done.
remote: Counting objects: 100% (274/274), done.
remote: Compressing objects: 100% (229/229), done.
remote: Total 274 (delta 77), reused 113 (delta 35), pack-reused 0
Receiving objects: 100% (274/274), 961.27 KiB | 5.86 MiB/s, done.
Resolving deltas: 100% (77/77), done.
real 0m1.353s
user 0m0.168s
sys 0m0.088s
Re: C++ Unit testing framework up and running
It's not required, but our QA strongly recommends adding a test phase, so users have the choice whether they want or don't want to run the tests while building (installing) the package. Also when stabilizing a package the test phase is usually run.adrianinsaval wrote: ↑Sat Feb 04, 2023 12:15 pm I thought it wasn't necessary to compile and run the tests when packaging?
Re: C++ Unit testing framework up and running
cMake provides this as a built-in facility, don't they? It's been a while, but my recollection is that cMake has a method for doing exactly what you describe, and with basically this exact use-case in mind. I'll try to remember to look at it when I am back in the States next week, there's a lot going on in the FreeCAD world right now . Ping me if I forget...
Re: C++ Unit testing framework up and running
A previous https://github.com/FreeCAD/FreeCAD/pull/8078/commits included:
I guess this could be used conditionally if find_package fails to find the module on the system. There are a couple of variations on the theme in cmake.
Would something like that achieve what you are looking for?
Code: Select all
include(FetchContent)
FetchContent_Declare(
googletest
# Specify the commit you depend on and update it regularly.
GIT_REPOSITORY
URL
https://github.com/google/googletest/archive/3fa7f983c69f780378b4d1ad44d36030ca951ba6.zip
)
FetchContent_MakeAvailable(googletest)
Would something like that achieve what you are looking for?
Re: C++ Unit testing framework up and running
Yes it's built into cmake. I think it could be used in a conditional way, like the example code from my first commentchennes wrote: ↑Sat Feb 04, 2023 8:40 pm cMake provides this as a built-in facility, don't they? It's been a while, but my recollection is that cMake has a method for doing exactly what you describe, and with basically this exact use-case in mind. I'll try to remember to look at it when I am back in the States next week, there's a lot going on in the FreeCAD world right now . Ping me if I forget...
We would have to test it, but that's the way, I was thinking on how this could be done.
Re: C++ Unit testing framework up and running
@waebbl yes, my suggestion is just as you say. Sorry I didn't credit you - missed it.
One thing to consider: Do you want to fix a version (like my old PR) and update manually from time to time, or always go for latest. Each has its own problems.
One thing to consider: Do you want to fix a version (like my old PR) and update manually from time to time, or always go for latest. Each has its own problems.
Re: C++ Unit testing framework up and running
Wouldn't it be easier to use the Google Test repo as a git sub-module, then?
Re: C++ Unit testing framework up and running
No worries. I just repeated it because I was thinking it might have been overlooked.
I honestly have not much expierence in this. Currently we have three gtest versions in our repository, 1.11.0 (stable), 1.13.0 (unstable) and a so-called live ebuild, i.e. the git master sources, for the very experimental users. The versions usually move quite fast, whenever Google releases new versions. And once 1.13.0 has been stabilized, 1.11.0 will usually go away quickly. From my POV, the version doesn't have a big significance, though I'm aware that Google might change the testsuite and tests will suddenly start to fail. But I guess, if that's the case this will get identified quickly and the test case sources could be updated.One thing to consider: Do you want to fix a version (like my old PR) and update manually from time to time, or always go for latest. Each has its own problems.
How's the situation with other distributions? Which versions do they have available? I have no clue for OSX and Windows though. Debian usually moves more conservatively, but Ubuntu, Fedora, Arch are moving quite fast as well when new versions get out. I could think of fixing to one version of gtest within a specific release of FC, for example use 1.13.0 for the 0.20 FC release cycle and move to a newer version of gtest, once the next FC release cycle starts. This *could* lead to incompatibilities, if we don't have that specific gtest version available any more in our repo. But that's something we need to handle on the distribution side and are used to cope with somehow. I would not request a specific version though, but only request GTest. If this shows to be too volatile we might still think about going a more conservative way.
I guess it wouldn't get included into the tarball then? Earlier I just assumed, that any possible platform does have gtest available, but I haven't verified this, especially not for non-linux platforms. If it's available everywhere, I think a git sub-module could be used as well. We just need to teach the package maintainers to add a dependency on gtest into their build recipes, if testing is required and developers to pull sub-modules as well.
Re: C++ Unit testing framework up and running
Why should package maintainers be affected? The unit testing framework IMO is a pure development thing that is only executed on a developer's machine and shouldn't be part of the application package. From a technical point of view the unit tests create stand-alone applications where all the Google test code is linked statically.We just need to teach the package maintainers to add a dependency on gtest into their build recipes, if testing is required and developers to pull sub-modules as well.