14:30:39 #startmeeting 14:30:39 Meeting started Tue Mar 27 14:30:39 2012 UTC. The chair is mmrazik. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 14:30:39 14:30:39 Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired 14:31:00 hi 14:31:08 We are here to have a public meeting on QA stuff we do in Product Strategy 14:31:34 today we would like to share some details on what we do with utouch in terms of quality 14:31:44 [TOPIC] unit and integration testing for the utouch-stack 14:31:52 tvoss: its yours :) 14:32:06 mmrazik, thanks :) 14:32:23 Hi all, my name is Thomas and I'm working as a quality engineer in the utouch team 14:32:54 let me present the "architecture" of utouch briefly 14:33:12 the stack mainly consists of 3 (4) components 14:33:46 utouch-frame is an abstraction layer that takes care of device, window and touch event handling 14:34:07 and it abstracts away from "platform specifics" regarding touches 14:34:31 utouch-grail sits on top of utouch-frame and provides gesture recognition capablities 14:35:01 utouch-geis integrates both utouch-frame and grail to provide gesture recognition services to applications via different interfaces 14:35:05 for example: DBus 14:35:46 finally, we have utouch-evemu optionally below frame 14:36:25 obviously, a stack like utouch requires both unit-testing and integration-testing 14:37:23 for both purposes, we rely on utouch-evemu to inject "fake" input events to the system 14:37:44 and this testing/injection layer allows us to record and replay corner/test cases 14:38:45 we use google test and its extension xorg-gtest to implement both our unit _and_ our integration testing 14:38:50 tvoss: so evemu exists just for testing purposes? Or is it needed in production environment as well. 14:39:14 mmrazik, evemu is mainly used for testing purposes 14:39:47 it relies on a kernel interface (uinput) to inject input events even below X 14:39:56 ok. I was just curious 14:39:58 (it used to be a runtime dependency in the old utouch stack, but isn't anymore) 14:40:18 as X and XI 2.2 are parts of our stack as well 14:40:34 any other questions so far? 14:41:17 * MrChrisDruif waits for the full "presentation" 14:41:50 a quick side note on xorg-gtest: it's a google test fixture/testing environment that takes care of starting/stopping a dummy x server environment 14:43:06 in our integration testing scenarios, we rely on xorg-gtest to start up a dummy server, insert fake events via evemu, and let them pass through the X server to utouch-frame 14:43:24 and to utouch-grail subsequently 14:44:13 with this chain in place, we are able to test both touch handling and gesture recognition with the help of pre-recorded touch sequences 14:45:06 so far for the actual testing setup. are there any questions? If not, I would go on with our continouos integration architecutre 14:45:26 just curious -- how many tests do we have in place right now? 14:45:29 for the integration part 14:45:56 mmrazik, all together, I would estimate like 20 overall cases 14:46:13 where each case might contain different types of gestures to be recognized etc 14:46:30 grail has 18, frame has 2 or 3 14:46:33 some of them are regression tests 14:46:39 cnd, thanks 14:46:40 geis has maybe 5? 14:47:06 thx 14:47:36 okay :) 14:48:00 we use jenkins for continouos integration purposes 14:48:49 and we recently started working on a virtualization setup that allows us to build _and_ test frame, grail and geis in a vm 14:49:17 this allows us to do ci both for different releases/versions of ubuntu and for different platforms 14:49:37 currently, we run our builds and tests for precise on both i386 and amd64 14:50:20 but we are planning to extend this to further versions and platforms in the future 14:50:50 I'd highly suggest ARM 14:51:06 MrChrisDruif, yeah, we are working on that 14:51:36 Seeing most tablets and smartphones are ARM, I wonder why that wasn't the first one 14:52:29 MrChrisDruif, well, problem here is the availability of vm's 14:53:00 only qemu supports arm at the present moment (at least, for alien host architectures) 14:53:06 MrChrisDruif, also, the code is platform agnostic 14:53:23 the tests will likely catch trivial bugs like variable size differences 14:53:36 MrChrisDruif: and HW in general. While our lab is "full" of x86* HW we don't have ARM ATM. 14:53:48 but as tvoss said. It is on our radar and we are actively working on this 14:54:05 the current plan is to have a functional setup for ARM testing for the 12.10 development cycle 14:54:10 which starts in few months 14:54:20 actually its more like a month 14:54:28 mmrazik, indeed :) 14:55:43 okay, putting all of the parts together, we are currently running builds and all of the tests for every merge to the trunk's projects 14:56:05 Great, thanks (had to check what agnostic code meant) 14:56:31 developers are provided with the unit test results/build logs and code coverage analysis results 14:56:43 (P.s.: 12.04 is in 30 days, so less then a month) 14:57:03 for the latter, we rely on instrumented code and gcov/lcov/gcovr to extract the results 14:57:10 MrChrisDruif: ack 14:57:15 MrChrisDruif, thanks 14:57:57 any other questions? 15:00:01 well, thanks for reading then :) 15:00:06 tvoss: thanks for the presentation 15:00:16 mmrazik, yw :) 15:00:36 thanks everybody for participating and see you next month 15:00:40 #endmeeting