[Qt-creator] Unit testing private parts of shared libraries

Elvis Stansvik elvstone at gmail.com
Mon Oct 16 19:04:43 CEST 2017


2017-10-16 18:57 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
> Hi all,
>
> (Posting this as a new thread instead of necroposting to my old thread
> about the design of Qt Creator [1], which did end with some
> discussions about testing.)
>
> I'm working on some tests for my own application, and started thinking
> about unit testing of private parts of shared libraries (think the
> _p.h/_p.cpp parts). Such parts are normally not exported AFAIK (in the
> visibility attribute sense). This becomes a problem if you link the
> unit tests dynamically against the code under test, as the tests won't
> be able to see those symbols.
>
> So it seems to me there is only a few options:
>
>  1. Exporting the private parts after all,
>  2. Adding the sources of the code under test to the unit tests,
>  3. ?
>
> 1 is not really good, as you export more than you really have to. But

And build times go up as well of course.

Elvis

> I guess it's not so bad after all, since you a) have to include _p.h
> to get at them and b) they're normally called PrivateSomething or
> InternalSomething, both of which should tell you you're doing
> something bad. 2 is not really good either though, as you really want
> to test the code as shipped, not as compiled as part of your test.
>
> I had a quick look at Qt Creator because I know you folks are seasoned
> developers, and it looks like you've gone with option 1. For example,
> ExtensionSystem::Internal::PluginSpecPrivate is exported, and I guess
> the reason is you want to be able to unit test it?
>
> I just wanted to ask in case you have any other ideas or better ways
> to let unit tests access things that are normally not exported?
>
> Thanks in advance,
> Elvis
>
> [1] http://lists.qt-project.org/pipermail/qt-creator/2017-September/006712.html



More information about the Qt-creator mailing list