D Unittest shortcomings with DLLs

[TheFlyingFiddle via Digitalmars-d]

On Tuesday, 3 March 2015 at 17:49:07 UTC, Benjamin Thaut wrote:
> Any suggestions how to fix this issue? I'm also open for 
> implementation hints.
>
> Kind Regards
> Benjamin Thaut

Running unittests that access private symbols from the other side 
of the dll boundary sounds like a very hard problem to solve. On 
one hand you want to be able to access the symbols in order to 
run the unittests and on the other hand they should be private to 
clients of the api. The question is do we even want to run 
unittests that test private implementation on the other side of 
the dll boundery at all? These unittests test functionality the 
users of the dll are unable to access. As such they are not 
actually testing if symbols that should be exported are. However 
unittests that test the public interface of a module do. I think 
that any tool that is created should only care about the 
unittests which are testing the public interface of the module. 
Since this is the interface users of the dll will interact with.

Given the above, a tool will have to be able to identify if a 
unittest tests a public interface of a module and only extract 
the unittests that do. Since these unittests only test the public 
interface they should be able to be compiled if the programmer 
has remembered to export all the public interfaces.

You still have a problem if the unittest is actually testing the 
public interfaces but makes use of some private helper function 
in the process. Since this would not be identified by the tool as 
a public interface-testing unittest.
This problem would not matter if unittest that test the public 
interface are written in another testing module. In my opinion 
these kinds of unittests that test the public interface should 
always be written in another module to ensure that they don't 
unintentionally make use of private symbols.

Finding out if a unittest only accesses public symbols could be 
done by analyzing the ast of the method. Either inside the 
compiler of via one of the third party D parsers currently in use.

I hope that this reply was somewhat helpful to you.