Best-practise currently for testing internal parts of libs? *_TEST_EXPORT macro?

Jeremy Whiting jpwhiting at
Mon Aug 31 16:29:52 BST 2015

The way the knewstuff tests work is by linking the source files being
tested directly. For example the Entry test also links entry.cpp and
entry.h directly. This way it doesn't need to have Entry private
methods exported at all. This may or may not be the best way to do it
though, but has worked ok there and was the suggestion when I had the
same question when reenabling KNewStuff unit tests a year or so ago.

On Mon, Aug 31, 2015 at 6:41 AM, Friedrich W. H. Kossebau
<kossebau at> wrote:
> Hi,
> what approach is best-practise currently for testing internal parts of libs?
> E.g. by symbols (classes) are not exported by default?
> In Calligra we have code that uses XYZ_TEST_EXPORT macros for those symbols
> which should be only exported in test-enabled builds, e.g. by defining
> COMPILING_TESTS to true and having code in the export header like
> #if defined _WIN32 || defined _WIN64
> # if defined(calligrasheetsodf_EXPORTS)
> #   else
> #   endif
> # else /* not windows */
> # endif
> #else /* not compiling tests */
> #endif
> But when switching to generated export headers, using cmake's
> generate_export_header macro, this seems no longer an option.
> Grepping for TEST_EXPORT on points that this seems an older
> approach which only might have survived in the island of Calligra :) when the
> rest of KDE world evolved to something else?
> So what are others doing?
> The only place pointed out to use the *TEST_EXPORT approach was
> grantlee, which simply creates a separate file with the define that then is
> appended to the file generated with generate_export_header:
> Seems a working hack which we could copy. But not sure if this is the best way
> and if this should not be done more generically?
> Cheers
> Friedrich

More information about the kde-core-devel mailing list