D Unittest shortcomings with DLLs

Benjamin Thaut via Digitalmars-d digitalmars-d at puremagic.com
Tue Mar 3 09:49:08 PST 2015


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.

Kind Regards
Benjamin Thaut



More information about the Digitalmars-d mailing list