Just found this paper. http://swwxguitesting.wefi.net/MPhilThesisChapterSwWxGuiTesting.pdf (about automated gui testing with wx) I personally think more gui code should move from C++ to python for easy development and interactive testing. Keep it going!! Greetings, Edwin van den Oetelaar
2013/4/28 Miguel Angel Ajo <[email protected]> > I agree that some kind of automated QA tests for the project would be > great, Adam wolf and I > had a conversation about that recently. > > I've seen many projects dramatically increasing quality because of > regression testing. I'm not > sure how well is wx prepared for the UI parts, but we can do it for sure > at objects level. > > Even, to reduce the test development time, we could even think of writing > the tests in python > directly, at least at pcbnew I think it can be done. > > > Miguel Angel Ajo > http://www.nbee.es > +34911407752 > skype: ajoajoajo > > On Sunday, 28 de April de 2013 at 17:54, Brian Sidebotham wrote: > > Hi Guys, > > I'm just catching up with the list, and I saw something that caught my eye > as it's something that's been on my mind for a while: > > -------------------------- > > Dick Hollenbeck wrote: > > - Right now, I am finding too many bugs in the software ... > > - We might do well as a team by slowing down and focusing > - on reliability and quality not features for awhile. Firstly, > - the bugs are damaging to the project. > > --------------------------- > > I agree with this, there are things I'd like to add to KiCad, but only > on-top of something I can be confident I'm not breaking, especially by > creating corner case issues. > > I would like us to think about regression testing using something like > CTest (Which would make sense as we're currently using CMake anyway!). We > could then publish dashboard regression testing results. > > I'm aware work is going into making eeschema and PCBNEW essentially into > DLL's, so perhaps it's best to wait until that work is complete before > starting down this road? > > In particular I'd like to see regression testing on the DRC, Gerber > generation, and the Python exposed API. Probably in that order of priority > too. Certainly the Python API changes are already tripping us up, but only > when they have already been broken in committed code. > > Being able to regression test changes to optimisations and code tidying > will help that move along anyway as you can be more confident in your > changes having complete coverage once the number of tests increases. > > I am prepared to say that I'll undertake this work too. Obviously it can't > start straight away as I'm currently doing work on the Windows scripting > build system and python-a-mingw-us packaging. > > Is anyone against regression testing, or have alternatives that would > achieve similar confidence in committed code? My vote is for regression > testing. > > We would need good support from all, new code requires new tests, and > nobody is better suited to devising the tests than the person who specified > the new functionality - which means all developers would probably end up > writing test cases at some point. > > Best Regards, Brian. > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [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 > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
