boostorg / test

The reference C++ unit testing framework (TDD, xUnit, C++03/11/14/17)
http://boost.org/libs/test
Boost Software License 1.0
183 stars 140 forks source link

Better cmake/ctest integration #341

Open t-b opened 2 years ago

t-b commented 2 years ago

I started using Boost.Test (again) in a new project. I would like to use cmake/ctest for building and test management. Unfortunately this is not easy possible with 1.74 (debian bullseye). In case it is interesting my current version is in https://gitlab.com/tango-controls/TangoDatabase/-/merge_requests/47. I've followed the https://eb2.co/blog/2015/06/driving-boost.test-with-cmake/.

Current shortcomings:

Is there a better approach? Or am I forcing ctest over Boost.Test which is the "wrong" approach?

raffienficiaud commented 2 years ago

Hi there,

The blog post your are pointing me to basically makes CTest the first citizen. I believe this was written before the integration of Junit into Boost.Test and the approach can be simplified.

I use CTest as a test driver driver only (running things in parallel, indicating the resources etc) and it is quite handy in case something really goes wrong with the test module itself. However I never use CMake or CTest for introspection of the code, as Boost.Test can generate JUnit files that are detailed enough. Those JUnit reports are then interpreted by the CI framework (Bamboo, Jenkins, etc) and a clear report can be visualized.

Junit files can contain many tests, and they also show the test suite.

To summarize:

  1. one test module (ie many test units and test cases) => one JUnit
  2. no introspection of the code from an external tool
  3. report from the CI directly from the JUnit

Does that work?

t-b commented 1 year ago

Thanks for the detailed answer.

The main reason for the code instrospection is that this allows to execute single test cases with CTest and also allows per test case progress output in ctest. I don't see a way currently to do that without code introspection.