Allow for editing with Test Window Open?
stagg54 opened this issue · 6 comments
I have no idea how doable this is with the LUnit Architecture. I know it was doable with VI Tester. I'm not sure the difference is.
Basically in VI Tester if ran all the tests and one test failed I can doubleclick on the failed test in the Test GUI Window and it opens up the test vi. LUnit does the same. So far, so good.
However, when the test VI opens in VI Tester I can edit it. Then I can just save the test and use the run one test button in the GUI and it runs the one test and I can verify if I fixed the test or not. If I fixed it, then for good measure I can then run all the tests to make sure I didn't break anything else. Makes troubleshooting very easy.
With LUnit, the problem is that the test VI is locked for some reason... Not sure why that is. You might consult with Darren. My immediate thought is something to do with application instances. As is I have to close the LUnit GUI in order to switch the test VI to edit mode. Now I've lost the test GUI window. It just makes troubleshooting a little harder.
As I mentioned VITester does open it in edit mode so under circumstances it is possible. I'm not sure how different the LUnit architecture is.
Anyway, if that could be fixed it would make my life a lot easier.
That sounds reheaally painful. Interestingly I do not see the same behavior. Are your test methods by any chance configured as Dynamic Dispatch? This would cause them to be locked while the UI is open as the Test Case.lvclass is loaded in memory.
I'm not in front of that project right now. That could very well be the case. I will check tomorrow.
Alright, thanks.
Are you (or anyone else) using the dynamic test methods? Now I mean in the sense of how it was originally intended, where a test case would inherit tests from parent test case classes and the tests would be run for each class in the hierarchy.
This was an idea I had and found useful a few years ago, but I am not using it in any other projects and I would guess no-one else is either. Since it adds complexity I'm considering deprecating it or potentially changing the implementation. As a first step the dynamic .vit-file should probably be dropped from the test case class generated by the framework.
I had the idea of doing that one time when I was using VI Tester.
I thought it would be nice to somehow take a child class and run all the parent tests on it and then add some tests for the child specifically. In theory it sounded great, but it never really panned out, mostly because VI Tester didn't support it, and then I forgot about it.
Yeah, this was my inital idea as well. It felt like it should have been a thing. I was at the time working on a framework and wanted to ensure that each class derived from the framework class would behave as expected. I took it pretty far but eventually realized that those inherited tests very rarely failed. So I ended up not running them.
I can confirm that dynamic dispatch was the problem. All works as expected now after making the test methods static.
As far as I am concerned you can close this issue.