D Unittest shortcomings with DLLs

[Jacob Carlborg via Digitalmars-d]

On 2015-03-03 18:49, Benjamin Thaut wrote:
> I'm currently in the process of annotating all of phobos with "export"
> and its quite cumbersome. To verify that I annoted all relevant
> functions and types with export I would like to run the unitests against
> the shared version of phobos. There is a problem with this though. The
> unittests are always compiled into the same binary the modules are in so
> the unittests would end up in the phobos.dll and would not test phobos
> across a shared library boundary. It would also be very usefull to have
> this verifycation for the future when DLL support is officially in and
> new features need to be tested if they are propperly annotated with
> "export". Once "export" is used for shared library symbol visibility on
> non-windows as well this will be an issue on all pattforms.
>
> The best solution would be if you could simply compile the unittests and
> just the unittests into a executable. This would require some compiler
> modifications, but even when done would cause some problems:
> - Unittests may use private functions / types of a module. Private
> functions and types are however not exported from an shared library so
> this would require making a lot of private functions / types public just
> to be able to run the unittests.
>
> Instead of building this into the compiler you could use a tool which
> extracts all "unittest { }" blocks out of all source files and puts them
> into new .d files. Then compile these into an executable. Now the code
> would not even compile because private symbols would not be accessible.
>
> Any suggestions how to fix this issue? I'm also open for implementation
> hints.

Sounds like you want to test an application that uses Phobos as a DLL. 
To me that sounds like a more higher level test than a unit test, i.e. 
integration tests. I would put those tests in completely separate files, 
in a separate testing directory. Then it should be no problem to compile 
the parts separately.

As for private functions. That is more a question of if you really 
should write specific test for those or just test the public API. If you 
really want to, you can bypass the protection using pointers.

BTW, I think we need to have integration tests in general. Testing how 
different parts/modules interact with each other.

-- 
/Jacob Carlborg