Martin, You're absolutely right about having hardware involved in the unit tests. They are strictly for my internal testing. Testing the code live in GNU Radio is turning out to be a serious headache =\
I have a solution in place right now that works around the second test, but it's nasty. Global variables and whatnot. I didn't think about the fact that some people need the XML output. Thank you for the explanation! -Dave On Thu, Jun 16, 2016 at 7:38 PM, Martin Braun <martin.br...@ettus.com> wrote: > I don't think this is an accident; when we run the tests on our CIs, we > want both the regular output and the XML output. You're right that this > behaviour can be annoying, however, I found if this is giving me > trouble, it's usually because my test is stateful. Maybe you can come up > with a way to actually run this test twice in a row. > > Having unit tests that require hardware is unusual, in any case. Now of > course you can write whatever tests you like, but this kind of unit test > will make it difficult for others to replicate (and to integrate into a > CI system, which I find a useful benchmark for the utility of unit tests). > > That said, we should probably come up with a way to disable the > xmlrunner (maybe make it a pref), since most people won't care about it. > > M > > On 06/15/2016 03:44 PM, Dave NotTelling wrote: > > I noticed that my Python unit tests were running twice. Using PyCharm's > > debugger I was able to figure out that the culprit is the following > > snippet from gr_unittest.py: > > > > # use the xmlrunner if we can write the the directory > > if(xmlrunner is not None): > > xmlrunner.run(suite) > > > > main() > > > > > > xmlrunner.run(suite) runs my tests, when that finishes (failure or not) > > main() gets called which runs the tests again. This plays hell with my > > tests that talk to radio hardware as the radio hardware is never > > released. Should there be an 'else' clause that calls main()? > > > > Thanks! > > > > -Dave > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio