How do C programmers do unit testing?

[M. Edward (Ed) Borasky]

This may seem like a silly question, but how do C programmers (assume
gcc/linux for now) do behavior-driven/test-driven development? Aside
from the obvious cheat (using RSpec to compile, link and execute the C
code) are there tools in C to do this?

 

[Eric Mahurin]

[Note: parts of this message were removed to make it a legal post.]

This may seem like a silly question, but how do C programmers (assume
gcc/linux for now) do behavior-driven/test-driven development? Aside
from the obvious cheat (using RSpec to compile, link and execute the C
code) are there tools in C to do this?

I use boost::test since boost is a standard linux install package. boost
has a bunch of great things to complement stl.

 

[Francis Cianfrocca]

[Note: parts of this message were removed to make it a legal post.]

This may seem like a silly question, but how do C programmers (assume
gcc/linux for now) do behavior-driven/test-driven development? Aside
from the obvious cheat (using RSpec to compile, link and execute the C
code) are there tools in C to do this?

I've gotten into the habit of writing wrapper libraries around C code and
unit-testing them with Ruby.

 

[Tim Pease]

This may seem like a silly question, but how do C programmers
(assume gcc/linux for now) do behavior-driven/test-driven
development? Aside from the obvious cheat (using RSpec to compile,
link and execute the C code) are there tools in C to do this?

CUnit and CppUnit are the two biggies I remember from the old days.
Just a re-implementation of Kent Beck's unit testing pattern in C and C
++ respectively. JUnit was the one that first made unit testing fun
and popular. Everyone else has pretty much cloned what was done there.

RSpec has been a breath of fresh air. Thanks, Ed

Blessings,
TwP

<http://cunit.sourceforge.net/>
<http://cppunit.sourceforge.net/>

 

[Phlip]

I've gotten into the habit of writing wrapper libraries around C code and
unit-testing them with Ruby.

That is seductive and wrong. Unit tests should be in the same language as the
tested code, or at least in a language that cross-compiles. I would TDD C using
UnitTest++, by cross-compiling to C++. There are also nice C-only test rigs
available.

However, the reason we use C is for super-wide portability (witness Ruby's
source code), and portability to embedded platforms like modern earrings. So
this implies we should run all the tests inside the platform, to smoke-test it.

So the question leads back to: Why use C?

 

[Jano Svitok]

I use boost::test since boost is a standard linux install package. boost
has a bunch of great things to complement stl.

I second this - I have used CxxTest in my Symbian days, then used it a
bit on windows,
and now we are using boost::test. So far it's good, but the test I
have are quite small.

 

[Tom M]

[Note: parts of this message were removed to make it a legal post.]

This may seem like a silly question, but how do C programmers (assume
gcc/linux for now) do behavior-driven/test-driven development? Aside
from the obvious cheat (using RSpec to compile, link and execute the C
code) are there tools in C to do this?

I use boost::test since boost is a standard linux install package. boost
has a bunch of great things to complement stl.

I use a nice little package called CuTest.

 

[Adrian Howard]

This may seem like a silly question, but how do C programmers
(assume gcc/linux for now) do behavior-driven/test-driven
development? Aside from the obvious cheat (using RSpec to compile,
link and execute the C code) are there tools in C to do this?

Yup. A whole bunch. There was a recent thread on the XP list that
covered many options. See <http://tinyurl.com/24dn89>

Cheers,

Adrian

 

[Dean Wampler]

[Note: parts of this message were removed to make it a legal post.]

This may seem like a silly question, but how do C programmers (assume
gcc/linux for now) do behavior-driven/test-driven development? Aside
from the obvious cheat (using RSpec to compile, link and execute the C
code) are there tools in C to do this?

I blogged about the "obvious cheat" recently. It's an "automate-able" way to
expose C and C++ to Ruby, and hence RSpec, using SWIG. (That is, it could be
automated and I hope to do that eventually).
http://blog.objectmentor.com/articles/2008/02/04/unit-testing-c-and-c-with-ruby-and-rspec

It should work pretty well right now for C. There are some issues still with
C++.

Dean Wampler
http://www.objectmentor.com
http://www.aspectprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org

 

[ara howard]

This may seem like a silly question, but how do C programmers
(assume gcc/linux for now) do behavior-driven/test-driven
development? Aside from the obvious cheat (using RSpec to compile,
link and execute the C code) are there tools in C to do this?

i used this long ago

http://cunit.sourceforge.net/



a @ http://drawohara.com/

 

[Dido Sevilla]

T24gRmViIDEzLCAyMDA4IDEyOjU1IEFNLCBNLiBFZHdhcmQgKEVkKSBCb3Jhc2t5IDx6bm1lYkBj
ZXNtYWlsLm5ldD4gd3JvdGU6Cj4gVGhpcyBtYXkgc2VlbSBsaWtlIGEgc2lsbHkgcXVlc3Rpb24s
IGJ1dCBob3cgZG8gQyBwcm9ncmFtbWVycyAoYXNzdW1lCj4gZ2NjL2xpbnV4IGZvciBub3cpIGRv
IGJlaGF2aW9yLWRyaXZlbi90ZXN0LWRyaXZlbiBkZXZlbG9wbWVudD8gQXNpZGUKPiBmcm9tIHRo
ZSBvYnZpb3VzIGNoZWF0ICh1c2luZyBSU3BlYyB0byBjb21waWxlLCBsaW5rIGFuZCBleGVjdXRl
IHRoZSBDCj4gY29kZSkgYXJlIHRoZXJlIHRvb2xzIGluIEMgdG8gZG8gdGhpcz8KCmh0dHA6Ly9j
aGVjay5zb3VyY2Vmb3JnZS5uZXQvCgotLSAK5pmu6YCa44GY44KD44Gq44GE44Gu44GM5b2T54S2
44Gq44KJ562U44GI44KL56eB44Gv5L2V44GM44Gn44GN44KL77yfCuaZrumAmuOBp+OCguaZrumA
muOBmOOCg+OBquOBj+OBpuaEn+OBmOOCi+OBvuOBvuaEn+OBmOOCi+OBk+OBqOOBoOOBkeOCkuOB
meOCi+OCiO+8gQpodHRwOi8vc3Rvcm13eXJtLmJsb2dzcG90LmNvbQo=

 

[Paul Brannan]

This may seem like a silly question, but how do C programmers (assume
gcc/linux for now) do behavior-driven/test-driven development? Aside
from the obvious cheat (using RSpec to compile, link and execute the C
code) are there tools in C to do this?

I've tried a bunch of the unit test frameworks for C++ but never liked
any of them, so I rolled my own. A test suite is in its own file and
looks like this:

TESTSUITE(MyTestSuite)

SETUP(MyTestSuite)
{
// put code here
}

TEARDOWN(MyTestSuite)
{
// put code here
}

TESTCASE(test_name)
{
ASSERT_EQUAL(true, true);
}

Though there's a lot that this model can't do (e.g. there's no
inheritance relationship between test suites), a big advantage here is
that you don't have to specify the test case names in two places as with
most other frameworks (once for the function definition and again to add
the function to the test suite). I'd worry that I'm reinventing the
wheel, except it only took an hour or so to implement.

It's included as part of Rice (rice.rubyforge.org).

Paul

 

[Arlen Cuss]

[Note: parts of this message were removed to make it a legal post.]

Hi,

On Wed, Feb 27, 2008 at 12:09 AM, Christian Neukirchen <

http://chneukirchen.org/repos/taptap/include/taptap.h

Very useful. Thanks

Arlen