I was thinking it would be nice to call the DETT programmatically, in particular:
1) Start and stop a capture
2) Save and load a configuration
3) Save the log file to a user-defined location
(4) Perhaps even compare log files, although this bit can also be done using existing technology
As we get used to more multithreaded programming ideas, such as the actor framework, the DETT will become more important as debugging with independently executing clones is not straightforward. One such really nice feature for the AF has been created by niACS (https://decibel.ni.com/content/docs/DOC-44158).
The next step to me now is to allow it to be called, for example, during a unit test, so that I can measure performance. There is clearly a chicken and egg problem, because the code in which I call the event may preload the code under test, but I can easily imagine being able to set up and tear down the test using different VI's.
How will this help?
1) We can do something correctly, record the trace, save the file and then diff a unit test against the good file, checking that it still produces the same output (if we fire user events as niACS did with the AF). This might not be the best way of unit testing (we ideally develop the test before the code, a la Test Driven Development) but we also should be allowed perhaps to look inside the process (white box testing) to see if more calls are used, say, than the last time the code was run.
2) We can create performance benchmarks for code with tests that are easily re-run. Sure, we ideally should use the same machine with no more software than the last time the test was run, But we can also
a) See variation across different machines, platforms, etc.
b) Assess code smells at a quantitative level
c) Assess upgrades across versions of Labview
