kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Miguel,

Sorry, I also was evaluating.  So I apologize for being hypocritical on that.

But you'll notice that I was very careful to remain neutral still at this point, and I was
analyzing mostly my own ideas.


Still, my bad.  You see, brainstorming does take some practice  :)

I think we'll probably end up with a good solution anyways.


Dick



 for sounding On 04/29/2013 11:27 AM, Dick Hollenbeck wrote:
> Technically, during the brainstorming process, it is best to gather ideas, and postpone
> passing judgement on those you have already heard, until the evaluation process, which
> comes later.  There is a theoretical reason why this is not to be done, and it supposedly
> thwarts creativity.
> 
> Creativity is the genesis of good ideas.
> 
> After the list of ideas is made, evaluation eventually begins.  When it is agreed that
> there are enough ideas to warrant the transition.
> 
> So your idea is CPPUnit.
> 
> Brainstorming is a fantastic tool, but admittedly it takes some understanding and
> agreement to follow it.
> 
> The notion of thwarting creativity is specifically one of the things brainstorming tries
> to avoid, since sometimes the best ideas end up being out of the norm.  Improvements come
> by challenging old ways.  If they fall into the waste bucket during the evaluation
> process, there is no harm at that point.
> 
> 
> Dick
> 
> 
> 
> 
> On 04/29/2013 10:40 AM, Miguel Angel Ajo wrote:
>> 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
>>
>