kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

If we evaluate cppunit, and run into issues when we try to make it
cross platform, I suggest looking at Google Test Framework, which is
like cppunit, but works better with regards to weird compilers.

Adam Wolf
Wayne and Layne, LLC

On Mon, Apr 29, 2013 at 11:33 AM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> 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
>>>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp