On Thu, 2014-06-12 at 15:03 +0300, Stoppa, Igor wrote: > Hello, > > On 12 June 2014 10:07, Patrick Ohly <[email protected]> wrote: > > Hello! > > > > A comment in JIRA about running unit testing sparked a debate in > > TIVI-1748 whether running automated tests as part of the OBS build of > > Tizen packages is feasible and/or desirable. This list here is a better > > place to discuss this. > > > > Traditionally, formal QA testing was (and still is) decoupled from > > development and packaging: > > I suppose that "Traditionally" is referred to Tizen only =) > But even that is not fully correct.
I was describing my experience as a developer contributing to Moblin, MeeGo and Tizen. During all that time, it has never been easy (or possible at all) for a developer to run the QA tests themselves before committing some potentially broken code into a git tree. It's good to hear that at least the REs now have an easier access to those tests; developers still don't. > > At > > each step of the process, the different people use different tests: > > developers maintain unit tests, release engineers have manual (?) > > checklists, QA maintains yet another set of tests. > > > > Developers have to maintain their own, project specific tests because > > otherwise they cannot ensure reliably that the code that they are > > committing is not causing regressions. Doing QA after packaging can't be > > a replacement for that, it would happen much too late in the development > > cycle. > > Hmm, I suspect hat here you intend "packaging" as "integrating into > the repo of accepted components and delivered as released image" > rather than "put in a .rpm .deb file". Right? Actually it's both: ideally, developers run tests before "git commit" and "gbs submit", so that's before packaging. > > Obviously this is often causing a duplication of effort on maintaining > > tests. In the past before Tizen, I tried to get QA engineers to > > contribute tests to SyncEvolution's original set of tests, without > > success. I also packaged these tests and provided instructions to QA on > > how to use them, which worked better until the QA engineer got > > reassigned. > > Personally I would prefer to make the job simple enough that the > developer can own completely the test cases used for own development. > Like you did. Ideally, I would like QA to be involved, too, but in general I agree, it should be the developers owning that task and QA engineers helping them. > There are, right now, means to do so. > Ex: fMBT [https://01.org/fmbt] > > this is what I'm relying on right now - I'll leave to Antti (added to > this thread) further commenting. There are plenty of test frameworks. The question still stands: are we allowed to run them as part of the .spec file and how do we get test results back out of an OBS build? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
