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 : [email protected] >> <mailto:[email protected]> >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
