multi-touch-dev team mailing list archive

[Duncan McGreggor <duncan.mcgreggor@xxxxxxxxxxxxx>]

On 08/19/2010 12:11 PM, Duncan McGreggor wrote:
> On 08/19/2010 11:37 AM, Duncan McGreggor wrote:
>> Hey guys,
>>
>> After some digging around today, Check seems like one of the best
>> options available for C unit testing. I'd be interested in hearing any
>> other open source C testing frameworks folks have used.
>>
>>  $ sudo apt-get install check
>>
>> I've been going through the tutorial here, and am quite pleased so far:
>>   http://check.sourceforge.net/doc/check_html/check_3.html
>>
>> However, since I haven't coded in C since 1989 and my only unit test
>> experience is in Python, I'd appreciated everyone sharing their thoughts.
>>
>> After a few days of discussion, we'll choose a framework for C unit
>> tests, and use that for a bit to see how it goes, uncover any issues, etc.
>>
>> Thanks!
>>
>> d
> 
> Stephen just mentioned dejagnu on IRC; the GCC project uses it. My only
> concern with it so far is that the language that the test runner is
> written is also the language that you write the tests in (Expect). Maybe
> that's good? I dunno... I'm just used to writing tests in the same
> language as the code that's being tested.
> 
> Maybe I'm not quite getting how dejagnu works, though?
> 
> I also am looking at CUnit right now, and this is looking nice as well:
>   http://cunit.sourceforge.net/doc/index.html
> 
> CUnit uses a different approach to defining unit test functions than
> Check does. More than that, though, it seems to offer a very nice set of
> higher level capabilities for tests suites. Similar to what I've used in
> Python and seen in Java.
> 
> d

Just chatted with Pete Graner on IRC, and he said that there's going to
be a lot of discussion around automated testing at UDS. He wants to get
OEM/Platform/HWE/Linaro all synced up on kernel/driver testing, and I'm
100% with him on this.

It's also a perfect opportunity for DX/MT to adopt a standard as well.

Pete and I will be keeping in touch over the coming days and weeks in
regard to testing and UDS sessions covering the topic, so DX/MT is sure
to be in the loop.

There's no reason to put our efforts on hold, though. In fact, it can
only help. We can join the discussions at UDS with some (small)
experience in hand and offer insights on the frameworks we've explored.

d