Re: [myhdl-list] Pythonic Test frameworks

[Christopher F. <chr...@gm...>]

On 11/7/11 7:21 PM, Bob Cunningham wrote:
> FWIW, py.test seems to be the way MyHDL itself is going...
>
> -BobC

Yeah we have had some brief conversations in the past, that py.test was 
a convenient test framework.  Some of the new tests are written for 
py.test.  But tests are still added under the unittest framework as 
well.  I don't know if it is accurate that MyHDL is moving towards 
py.test and away from unittest.  I think it depends what is being 
tested.  Example, the tests for the modbv (recent addition) were added 
in the unittest area.

I like the py.test but I have little experience with unittest and 
limited with py.test, case in point I was not aware (or forgot) of the 
setup/tear down capabilities.  I don't have enough information at this 
point to suggest one over the other.  It looks like, if you require 
teardown along with setup you will need unittest framework and not py.test.

The following, http://bit.ly/sc3vrI, is a brief mention of py.test used 
instead of unittest (from a couple years ago) from the myhdl-list.

But I do believe py.test is limited.  If you are ok writing with only 
simple asserts, I believe py.test is ok.  But unittest supports more 
advanced features, automatically verify raised exceptions (continue if 
raised fail if not).

I guess an argument against py.test, is that it is another package that 
needs to be installed.  Where as, unittest is part of the standard 
Python library, hmmm.

Regards,
Chris

>
>
> On 11/07/2011 02:15 PM, Christopher Felton wrote:
>> On 11/7/2011 3:50 PM, Uri Nix wrote:
>>> On 7 November 2011 08:30, Christopher Felton<chr...@gm...>    wrote:
>>>
>>>> Looking for some opinions on methods to make my testbenches more
>>>> Pythonic.  I have been humbled more often than not with my Python
>>>> programming skills, or lack there of (http://bit.ly/uQeRGm).  And my
>>>> testbenches seem to be old-school version of my Verilog/VHDL equivalent
>>>> testbences.  Looking to move from a testbench to a test framework.
>>>>
>>>> Frequently I will create a single testbench and have a bunch of
>>>> testcases in the testbench.  In some cases I will create multiple
>>>> (different) forms in test_ functions to use with py.test.
>>>>
>>>> But too often, majority of my test cases are in this single testbench.
>>>> What I would like to do is leverage the py.test framework but only
>>>> define connections, models, etc *once*.  Using the USB interface project
>>>> (USBP, http://bit.ly/sPEMC1) as an example I used something like the
>>>> following.
>>>>
>>>> ~~~ [Example Code] ~~~
>>>> class BaseSim()
>>>>
>>>>       def __init__(self, ...):
>>>>          # all top-level signal definitions, dut instance and interface
>>>>          # model instances
>>>>          ...
>>>>
>>>>      def GetGens():
>>>>          # return all the generators for
>>>>
>>>> def test_case1():
>>>>       bs = BaseSim()
>>>>
>>>>       @instance
>>>>       def tb_stimulus():
>>>>          yield bs.WriteRegister(0x00, 42)
>>>>          rval = [0]
>>>>          yield bs.ReadRegister(0x00, val)
>>>>          assert rval[0] == 42
>>>>          raise StopSimulation
>>>>
>>>>       Simulation((tb_stimulus, bs.GetGens())).run()
>>>>
>>>> def test_case2():
>>>>       bs = BaseSim()
>>>>
>>>>       @instance
>>>>       def tb_stimulus
>>>>          bs.someSignal.next = True
>>>>          yield delay(3)
>>>>          bs.someSignal.next = False
>>>>          # check some condition
>>>>          raise StopSimulation
>>>>
>>>>      Simulation((tb_stimulus, bs.GetGens())).run()
>>>>
>>>> ~~~ [End Example Code]~~~
>>>>
>>>> Other methods that are more flexible?  Is it worth it to add the
>>>> instantiations and connection signals to a class or just in a module?
>>>>
>>>> Thanks in advance,
>>>> Chris
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> RSA(R) Conference 2012
>>>> Save $700 by Nov 18
>>>> Register now
>>>> http://p.sf.net/sfu/rsa-sfdev2dev1
>>>> _______________________________________________
>>>> myhdl-list mailing list
>>>> myh...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>>>
>>> Hi Chris,
>>>
>>>      I find the standard lib unittest flexible enough, allowing something like
>>> the example below.
>>>      Any special reason for using py.test?
>> No special reason for the py.test.  I guess I have used py.test because
>> you simply create test_ functions and use asserts.  And I have not use
>> the unittest as much.  You pointed out the piece I think I was looking
>> for.  The idea of a setup!  This is where all the connections etc can be
>> defined and defined only once (thanks for the code example).
>>
>> Searching, py.test has a similar mechanism.  You need to define all the
>> test_ functions/methods in a class and use the "setup_method" which is
>> equivalent to the setUp in the unittest.
>>
>> Thanks!
>> Chris
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1