2017-10-16 18:57 GMT+02:00 Elvis Stansvik <elvst...@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 _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
