Mocking / Stubbing a Broadcast Event

[czab]

Hi All!

I am a beginner in DQMH and I'm still seeking its usage to the fullest potential - I'd also like to to test my modules as decoupled and isolated as possible - and this is the reason for the question at hand:

Imagine we have Continuous Measurement and Logging DQMH template - with Logger, UI, Acquisition and Settings module. In Logger API tester there is a nice way to log whatever waveform we want, because it is a simple Request Event. I'd like to extend the testability of the UI module to the same degree - to somehow create the <Acquisition.Data Updated> User Event from my tester, that would go the same path as the original Event - but remain in the scope of the module. This way I'd be able to verify the UI behavior without the need of running the whole code and I'd be able to test some corner cases.

Till now, I was able to come up with two approaches to this thing:

1. Create an additional Integration Tester, starting both CML UI and Acquisition DQMH modules. This would move us from "unit" testing to "integration" testing and this depends on how well the Acquisition module is written when it comes to decoupling it from hardware. This is something I am looking into, but I'd really prefer to be able to pass any random waveform instead and isolate my tests.

2. Make an additional Request Event that matches the data type of Acquisition Broadcast Event. This gives me the level of isolation I want, but I end up with additional API calls that are only valid for the tests and I need to pay attention that my other developers are not using those for anything other than testing - not to mention the mess it creates.

Is there anything I am missing in my exploration of DQMH features that might come in handy in occasions like this?

Bartosz

[Ozfarmboy]

Hi Bartosz,

If you were to draw a hierarchy diagram of the CML Template showing each DQMH module and their relationships, the CML UI would sit at the top.

The CML UI module depends on the rest of the modules - Settings, Acquisition, and Logger. It can't really run without it's dependencies.

So the way I see this is that the CML UI (and the modules underneath) are all one "unit".

At Wired-in we have taken two approaches to this in the past to test these higher modules:

1) Setup simulation modes in the lower modules.

In the Acquisition module, we typically have an enum that is editable in the Settings page.  This would be called Acq type, and the two options might be NI DAQ or Simulator.

When the modules are being setup, if the Acquisition module is setup to be a simulator, then it will generate simulated data when requested (or broadcast as the template does it by default).
This way you have more control over the data you're using during testing.

2) The other way is that you need to adjust your hierarchy a little.

ie. don't make the UI the top level module. In the CML template, the UI is performing as the UI, but also as the main Controller of the application.  What you can do is separate these two functions.

Create another module at the top of the tree that is the Controller and also acts as a message distributor. This controller module would launch all modules, including the CML UI module. The UI module simply becomes a UI - it doesn't talk to any other modules or do much other than display data and broadcast when buttons are pushed.

The Acq module broadcasts its data up to the controller, and then the Controller calls UI module requests to give it its data. 

On one hand there is double handling with the message data, but on the other hand, the UI module is not dependent on anything and achieves the isolation you're after.

But then now how to test the Controller module? 🙂

[czab]

Hi Christopher,

Thank you for your input and for the thorough explanation. I think I'll go with one of the approaches that you've suggested and make my peace with this 🙂

Prior to DQMH I used simple forms of dependency injection and loose coupling of the modules, so the hierarchy of most of my work would not be as obvious as in the example code.

There is also a dirty-hack that I find a little bit tempting - making a wrapper on broadcast event query of the module I'd like to mock and make it Community acces, with Friends set to the Tester of the module I'd like to test - unlike Actor Framework, Events are not secured on their handles - instead of using them just for the registration it is technically possible (although a little bit dirty) to Generate an Event in the tester, using this ref - but I'll try to fight my temptation here 😉

[FabiolaDelaCueva]

Hi Bartosz,

Have you checked out the unit testing tools for DQMH?

https://delacor.com/documentation/dqmh-html/CreatingDQMHUnitTests.html

Regards,

Fab