kicad-developers team mailing list archive

[Miguel Angel Ajo <miguelangel@xxxxxxx>]

I have the feeling that setting entry points from Python to C, when not needed will be an extra work and harder to maintain. In that
case why not just using C++ standard testing frameworks?, like CPPUnit, or something that plays well with wx for UI testing?

http://wiki.wxwidgets.org/Tools <-- Testing


We have two things to test:

1) UI/behaviour , this is usually done launching dialogs manually, and calling click methods, reading form entries, checking output, etc…,
Ideally it must be something like (warning, pseudocode)

dialog = MyDialog()

n = dialog->getListElements( 'list1' )
dialog->fillField( 'Field1','Content1' )
dialog->clickButton( 'Add' )
assert dialog->getListElements('list1')==(n+1)

2) Model testing: We call the back models with loads of tests to check their correct behavior

   a) Normal ones, just model behaviour, correct DRC checks,

   b) Models that generate outputs: In webkit, they just have pngs of the outputs renderings, and they xor/compare. In our case, we can make a diff of  
       the output contents with expected ones, or try to render them to PNG & test theme. (warning: needs extra maintenance when outputs are enhanced or change, but it will catch unexpected changes)

   c) Model testing from python, everything that's swigged out can be tested from there, and then we get a contract on what the available methods
   are to stay as fixed as possible. Even we get loads of examples out of this.


The automated tests I've seen so far (in the last two years) generate an xml standardized files (junit xml format) that's used for reports (I use them in bamboo at nbee, and also with other client for web ui testing, I've even used it to generate VHDL testing outputs from ghdl) http://projects.nbee.es:8085/browse/S12-DEF the bad thing of bamboo is that it doesn't play well with bzr (AFAIK)







Miguel Angel Ajo
http://www.nbee.es (http://www.nbee.es/)
+34911407752
skype: ajoajoajo


On Monday, 29 de April de 2013 at 17:06, Dick Hollenbeck wrote:

> >  
> > We could address a) and b) by having a single DLL/DSO specific entrypoint for all tests,
> > with a big switch in there to route to the actual test. This scaffolding has some
> > maintenance cost, and begins to wash out the ease of using python on top, but perhaps not
> > fully.
> >  
>  
>  
>  
> In the python C implementation code you find instances of the paradigm of va_args (tuple)
> with a C string telling which argument types are in the tuple. The C string is like a
> printf format string.
>  
> So it would be possible to make this callable from python and pass all required arguments
> for any worker function. You would have to instantiate the C++ instance before calling
> any member function which is your worker function. But that could be done in the switch
> within the test entrypoint.
>  
>  
> test_result TestEntryPoint( aTestNum, formatStringTellingArgumentTypesInTuple, Tuple )
> {
> switch( aTestNum )
> {
> case XYZ:
> {
> // instantiate what is needed, say obj
>  
> // gleen into C++ arguments, those from Tuple by parsing
> // formatStringTellingArgumentTypesInTuple
> va_args...
>  
> // call object member func with C++ form of arguments in tuple.
> result = obj->WorkerFunction( arg1, arg2, arg3 );
>  
> // destroy what we instantiated.
> }
> }
>  
> return test_result( result ) ; // telling what just happened.
> }
>  
>  
>  
> The above could be a seed for better ideas. It is a means of testing any "worker
> function" from python.
>  
>  
>  
>  
>  
>  
>  
>  
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>