[Qt-creator] Unit testing private parts of shared libraries
timur.kristof at gmail.com
timur.kristof at gmail.com
Tue Oct 17 19:57:02 CEST 2017
On Tue, 2017-10-17 at 19:53 +0200, Elvis Stansvik wrote:
> > > > What do you mean by "not testing the code exactly as shipped"?
> > > > When
> > > > you include the cpp file (or just compile the same file into
> > > > your
> > > > project), why isn't it the same code as shipped?
> > > > Sorry for my ignorance.
> > >
> > > I was talking about the compiled code. My bad for not being
> > > cleared.
> > > So what I meant with "as shipped" was "exactly the shared library
> > > file
> > > that will be part of the product".
> >
> > Well, you can make sure of that by using the exact same build
> > environment and compiler flags for your tests as your library. This
> > way
> > it will be the exact same compiled code, won't it?
>
> Yes, being diligent about doing that will of course minimize the
> risk,
> but nothing beats being absolutely sure.
>
> But just to be clear: I'm not saying that this is a necessity or
> anything, not at all. I was only bringing that up as one small
> downside to re-compiling your source as part of your tests, in the
> interest of comparing approaches to letting your tests get at the
> non-exported parts of your code.
I didn't mean to offend, only asked because I was curious about your
thoughts. :)
One more thing:
While I see why it is desireable to test the code exactly as shipped,
but there are also benefits to testing with different settings. For
instance, in one project I used the approach where I simply compiled my
library code into the tests. Then I ran the tests with various
optimization flags and they each helped me discover different kinds of
errors in the code.
So it might be worth to test with multiple build settings as well.
Cheers,
Timur
More information about the Qt-creator
mailing list