I am noticing that calling `CPPUNIT_ASSERT_MESSAGE("moo", 1 == 2)` in C++
unit tests does cause the test to fail, but does not print the message. Is
there something I need to do in order to get the output I expect? Not
having any output from the messages makes figuring out what happened a pain
in the butt =\
On Sun, Jun 12, 2016 at 10:14 AM, Dave NotTelling <dmp250...@gmail.com>
wrote:
> Sebastian,
>
> The module I'm testing has a lot of interconnected deps so I went
> about creating a standalone OOT module to test with. After spending about
> 30 minutes trying to figure out why it was hanging after getting to
> tearDown() I checked your E-Mail and realized that I had forgotten to put
> in self.tb.wait() after self.tb.stop(). At that point things worked just
> fine. I cannot test that change against the original module until Monday,
> but I have high hopes that I just forgot that one little bit.
>
> I've included my test code for anyone who wants to know how to test
> PMT only blocks. I think this is the only way to do it since there appears
> to be no way to inject PMT messages to the module under test. So, I used
> the method described by Marcus (linked in one of my previous E-Mails) of
> creating a producer that gets triggered by a vector source and then a
> consumer that gathers output from the module under test. If anyone has a
> better method I'd love to hear it! The only other thing I could think of
> was a message strobe which doesn't give me control over timing of
> individual PMTs.
>
> For those not well versed in C++, the foo_source block simply reads
> in a PMT that needs to be a dictionary containing the key 'bytes' and puts
> the value (a 64 bit unsigned int) into a vector (list for python folks).
> That vector is being read every 10 ms by a thread created by the foo_source
> block. When there are elements in the vector the thread will output X PMTs
> where X is the value from 'bytes'. There will be 10 ms between each PMT
> being output. It's meant to mimic the block I was having issues testing.
> I could have probably changed the class to inherit from gr.block instead of
> gr.sync_block, but meh. The test appears to work anyway :)
>
>
> Thank you very much!
>
> -Dave
>
> On Fri, Jun 10, 2016 at 3:10 AM, Sebastian Müller <gse...@gmail.com>
> wrote:
>
>> Hi Dave,
>>
>> if you need a block that just passes messages, try the Message Strobe. If
>> this is not what you want, can you please publish your block code so we can
>> reproduce the behaivour? From your error message, maybe you have forgotten
>> to put the "self" parameter in the method declaration? That is always
>> needed in python as first parameter of class methods.
>> Also, when you want to test flowgraphs with PMTs, you can't use
>> "self.tb.run()" but have to use a structure like this:
>>
>> # connecting and block instancing
>> self.tb.start()
>> time.sleep(0.5)
>> self.tb.stop()
>> self.tb.wait()
>> # assertion checks
>>
>> This lets the flowgraph run for 0.5 secs and stops it again.
>>
>> Cheers,
>> Sebastian
>>
>> 2016-06-09 15:47 GMT+02:00 Dave NotTelling <dmp250...@gmail.com>:
>>
>>> I am also noticing that the unit test runs twice. Is there a particular
>>> reason for that? Also, if I call self.assertTrue() on something I know is
>>> false ('1 == 2' for example) before self.tb.stop() is called, the test just
>>> hangs. If I call self.tb.stop() and then call the same assert statement,
>>> the test exits, but does not report the failure. I am testing a source
>>> block that only outputs PMTs and does so forever. I also tried calling
>>> myBlock.stop() in hopes that the stop() method would call the destructor
>>> but that didn't happen. How does one go about stopping a PMT only test
>>> bench?
>>>
>>> On Tue, Jun 7, 2016 at 6:45 PM, Dave NotTelling <dmp250...@gmail.com>
>>> wrote:
>>>
>>>> I would like to make some unit tests for a PMT only block I created,
>>>> but I haven't been able to find any good examples aside from a
>>>> StackOverflow post (
>>>> http://stackoverflow.com/questions/36342285/testing-a-gnu-radio-message-accepting-block-with-post).
>>>> The hope was that I could simply access the message port of the block under
>>>> test and shove PMT messages in there. Is that even possible? I tried
>>>> making a custom block as outlined in
>>>> https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/python/blocks/qa_python_message_passing.py
>>>> with the slight tweak of having a method called 'send' in the producer that
>>>> would send whatever PMT object you provide as an argument out to the output
>>>> message port. That fails with:
>>>>
>>>> message_gen.send(pmt.intern('asdf'))
>>>> TypeError: unbound method send() must be called with message_gen
>>>> instance as first argument (got swig_int_ptr instance instead)
>>>>
>>>>
>>>> Any tips to test a block like this?
>>>>
>>>> Thanks!
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
