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

Reply via email to