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

[Kevin Funk]

On Monday 31 August 2015 09:29:52 Jeremy Whiting wrote:
> 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.

Unfortunately that requires you to compile entry.cpp (at least) twice. Once 
for the shared lib, once for each unit test using it.

Another approach is to do something CMake tried to advocate with its OBJECT 
libraries. It has its flaws (not going further in details), and there's a 
similar approach using static libraries.

Taking your example further:
- Compile entry.cpp and all other files part of your lib into MyStaticLib
- Make test_entry.cpp link against MyStaticLib (no exports needed)
- Make the MyLib shared object link against MyStaticLib

The good:
- entry.cpp (and all others) only need to be compiled once

The bad (compared against a shared-object-only solution):
- each unit tests needs to be relinked in case MyStaticLib changes

We're using this approach in KDevelop plugins, successfully. Also to avoid any 
intermediate libs. We want the plugin to be self-contained, to reduce loading 
times and generally to reduce the number of installed libs.

PS: This approach is not really recommendable for large-scale projects like 
Calligra, I guess. Having to relink every unit test if you change some central 
implementation file is a no-go. Having a separate export macro like Friedrich 
suggested initially is the better thought.

> On Mon, Aug 31, 2015 at 6:41 AM, Friedrich W. H. Kossebau
> 
> <kossebau at kde.org> 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
> > 
> > #ifdef COMPILING_TESTS
> > #if defined _WIN32 || defined _WIN64
> > # if defined(calligrasheetsodf_EXPORTS)
> > #       define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT
> > #   else
> > #       define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_IMPORT
> > #   endif
> > # else /* not windows */
> > #   define CALLIGRA_SHEETS_ODF_TEST_EXPORT KDE_EXPORT
> > # endif
> > #else /* not compiling tests */
> > #   define CALLIGRA_SHEETS_ODF_TEST_EXPORT
> > #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 lxr.kde.org 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 lxr.kde.org 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:
> > http://lxr.kde.org/source/grantlee/templates/lib/CMakeLists.txt
> > 
> > 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

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150831/9d62d24d/attachment.sig>