Hey Antoine,
in general, it seems to be best practice to test a DQMH module through its public API. That way, the Caraya Unit Test VIs would stay outside your module's lvlib. I would even recommend saving them outside your projects source folder, because they don't really belong to your application's source code ( - but in the same repository). That way, you would be able to build on linux.
The downside of this approach is, that you cannot test the private subVIs of your DQMH module. One could argue, that it doesn't matter, as long as the public API works correct. But it still feels uncomfortable.
So I would try to create a class outside the module's lvlib, wrapping the core functionality which you want to test without the module. Since it is a public class, you can write another set of Unit Tests against that class. That class could also be used by different modules, in different projects without DQMH, or when you want to change your framework etc..
Having a tested class and a tested DQMH module, there is little need to test the private subVIs of the module. The downside of this approach is, that you will lose some visibility in the DQMH module: A look at one MHL-case might not show as much as before, because the implementation moved in the class.
The implementation of DQMH module communication in the application context on the one side and the functionality of the class (e.g. Hardware Abstraction Layer) on the other side, needs to be separated. E.g. you won't put broadcasts into the class, since it should be useable without the DQMH module. I feel that doing unit tests forces us for a cleaner design, which might be the reason for a headache, but worth it 😉
Just my ideas, I have been running into this problem also a few times and am curious about other solutions.
Alexander
