Loading ...
Sorry, an error occurred while loading the content.

Group vote for C unit testing framework

Expand Messages
  • Hugo Garcia
    Hi C doesn t seem to have a standard library for unit testing like other languages. Which framework do you use? If you are a framework author/contributor
    Message 1 of 19 , Jan 24, 2008
    • 0 Attachment
      Hi

      C doesn't seem to have a "standard" library for unit testing like
      other languages.

      Which framework do you use?

      If you are a framework author/contributor then please compare and
      contrast if the other frameworks.

      Thank You in advance.

      -H
    • tkjuho
      Hi Hugo, ... I use mainly GUnit (https://garage.maemo.org/projects/gunit/) nowadays, or some simple self made framework that suits my needs. Br, Tomi Juhola
      Message 2 of 19 , Jan 25, 2008
      • 0 Attachment
        Hi Hugo,

        > C doesn't seem to have a "standard" library for unit testing like
        > other languages.
        >
        > Which framework do you use?

        I use mainly GUnit (https://garage.maemo.org/projects/gunit/)
        nowadays, or some simple self made framework that suits my needs.

        Br,
        Tomi Juhola
        Specialist, Tieturi Oy
        http://www.tieturi.fi
      • Micron Engineering
        ... I use MinUnit and CUT for embedded projects. On Windows and Linux I use UnitTest++. For embedded projects we are working on an internal project to simplify
        Message 3 of 19 , Jan 25, 2008
        • 0 Attachment
          Hugo Garcia ha scritto:
          >
          > Hi
          >
          > C doesn't seem to have a "standard" library for unit testing like
          > other languages.
          >
          > Which framework do you use?
          >
          I use MinUnit and CUT for embedded projects. On Windows and Linux I use
          UnitTest++.
          For embedded projects we are working on an internal project to simplify
          a lot C and C++ remote testing.
          >
          > If you are a framework author/contributor then please compare and
          > contrast if the other frameworks.
          >
          > Thank You in advance.
          >
          > -H
          >
          > <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family:
          > Arial; margin: 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border:
          > 1px solid #d8d8d8; } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%;
          > font-weight: bold; line-height: 122%; margin: 10px 0px; } #ygrp-mkp
          > #ads{ margin-bottom: 10px; } #ygrp-mkp .ad{ padding: 0 0; } #ygrp-mkp
          > .ad a{ color: #0000ff; text-decoration: none; } --> <!--
          > #ygrp-sponsor #ygrp-lc{ font-family: Arial; } #ygrp-sponsor #ygrp-lc
          > #hd{ margin: 10px 0px; font-weight: bold; font-size: 78%;
          > line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{ margin-bottom: 10px;
          > padding: 0 0; } --> <!-- #ygrp-mlmsg {font-size:13px; font-family:
          > arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
          > #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
          > input, textarea {font:99% arial,helvetica,clean,sans-serif;}
          > #ygrp-mlmsg pre, code {font:115% monospace;*font-size:100%;}
          > #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family: Georgia;
          > } #ygrp-text p{ margin: 0 0 1em 0; } #ygrp-tpmsgs{ font-family:
          > Arial; clear: both; } #ygrp-vitnav{ padding-top: 10px; font-family:
          > Verdana; font-size: 77%; margin: 0; } #ygrp-vitnav a{ padding: 0 1px;
          > } #ygrp-actbar{ clear: both; margin: 25px 0; white-space:nowrap;
          > color: #666; text-align: right; } #ygrp-actbar .left{ float: left;
          > white-space:nowrap; } .bld{font-weight:bold;} #ygrp-grft{
          > font-family: Verdana; font-size: 77%; padding: 15px 0; } #ygrp-ft{
          > font-family: verdana; font-size: 77%; border-top: 1px solid #666;
          > padding: 5px 0; } #ygrp-mlmsg #logo{ padding-bottom: 10px; }
          > #ygrp-vital{ background-color: #e0ecee; margin-bottom: 20px; padding:
          > 2px 0 8px 8px; } #ygrp-vital #vithd{ font-size: 77%; font-family:
          > Verdana; font-weight: bold; color: #333; text-transform: uppercase; }
          > #ygrp-vital ul{ padding: 0; margin: 2px 0; } #ygrp-vital ul li{
          > list-style-type: none; clear: both; border: 1px solid #e0ecee; }
          > #ygrp-vital ul li .ct{ font-weight: bold; color: #ff7900; float:
          > right; width: 2em; text-align:right; padding-right: .5em; }
          > #ygrp-vital ul li .cat{ font-weight: bold; } #ygrp-vital a{
          > text-decoration: none; } #ygrp-vital a:hover{ text-decoration:
          > underline; } #ygrp-sponsor #hd{ color: #999; font-size: 77%; }
          > #ygrp-sponsor #ov{ padding: 6px 13px; background-color: #e0ecee;
          > margin-bottom: 20px; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px;
          > margin: 0; } #ygrp-sponsor #ov li{ list-style-type: square; padding:
          > 6px 0; font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration:
          > none; font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
          > margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding:
          > 8px 0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight:
          > bold; color: #628c2a; font-size: 100%; line-height: 122%; }
          > #ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad
          > a:hover{ text-decoration: underline; } #ygrp-sponsor .ad p{ margin:
          > 0; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{
          > font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4}
          > -->
          >
          > -------------------------
          >
          > No virus found in this incoming message. Checked by AVG Free Edition.
          > Version: 7.5.516 / Virus Database: 269.19.10/1240 - Release Date:
          > 23/01/2008 17.47




          [Non-text portions of this message have been removed]
        • Tim Ottinger
          CppUnit, CppUnitLite, CppUTest, TUT, unit++. CppUnit is actually pretty good if you don t build separate .cpp and .h files, but do your work all in the class
          Message 4 of 19 , Jan 25, 2008
          • 0 Attachment
            CppUnit, CppUnitLite, CppUTest, TUT, unit++.

            CppUnit is actually pretty good if you don't build separate .cpp and .h files, but do your
            work all in the class def in a cpp file. Otherwise you have that crazy triplicate "mother may
            I" work (declare, register, implement in three places). There are ways to make it easier,
            including writing vim macros (http://blog.objectmentor.com/articles/2007/05/03/cppunit-and-vim).

            TUT I particularly disliked.

            I prefer the frameworks that are amenable to a lot of small fixtures (more bdd-style)
            and no tools in perl or whatever to patch it up. I also prefer to have control over the
            output format so that I can make test errors look like compile errors to the editor or
            IDE I'm working with.

            But I would assume that CppUnit or unit++ were fairly "standard" if nobody told
            me any different. ;-)





            ----- Original Message ----
            From: tkjuho <tkjuho@...>
            To: extremeprogramming@yahoogroups.com
            Sent: Friday, January 25, 2008 10:13:52 AM
            Subject: [XP] Re: Group vote for C unit testing framework


            Hi Hugo,

            > C doesn't seem to have a "standard" library for unit testing like
            > other languages.
            >
            > Which framework do you use?

            I use mainly GUnit (https://garage.maemo.org/projects/gunit/)
            nowadays, or some simple self made framework that suits my needs.

            Br,
            Tomi Juhola
            Specialist, Tieturi Oy
            http://www.tieturi.fi



            To Post a message, send it to: extremeprogramming@...

            To Unsubscribe, send a blank message to:
            extremeprogramming-unsubscribe@...

            ad-free courtesy of objectmentor.com
            Yahoo! Groups Links









            ____________________________________________________________________________________
            Be a better friend, newshound, and
            know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


            [Non-text portions of this message have been removed]
          • Nancy Van Schooenderwoert
            I d like to point out CATSRunner, as a C unit testing framework especially written for use in embedded software. The original release is adapted for the ARM 7
            Message 5 of 19 , Jan 27, 2008
            • 0 Attachment
              I'd like to point out CATSRunner, as a C unit testing framework
              especially written for use in embedded software. The original release is
              adapted for the ARM 7 CPU, i.e. you can run your tests on ARM 7 and on a
              desktop PC. The idea is that the framework has a generic part and a part
              that needs to run on whatever your target CPU is. Users can port it to
              other target CPUs fairly simply. The work you'd do to port this is work
              you must do anyway to hook up debugging on your target CPU.

              http://freshmeat.net/projects/catsrunner/

              The above link gives info about this. I helped write this framework. The
              intent was to keep it all in C, to work for those unfamiliar with C++ or
              Perl, etc.

              This is rather specialised, and I haven't heard of other test frameworks
              that attempt to do the same - work in C, specifically for embedded
              software development.

              - njv

              --
              ----------------------------------------------------------------------
              Nancy Van Schooenderwoert Leading edge Agile coaching
              http://www.leanagilepartners.com


              Hugo Garcia wrote:
              > Hi
              >
              > C doesn't seem to have a "standard" library for unit testing like
              > other languages.
              >
              > Which framework do you use?
              >
              > If you are a framework author/contributor then please compare and
              > contrast if the other frameworks.
              >
              > Thank You in advance.
              >
              > -H
              >


              [Non-text portions of this message have been removed]
            • Manuel Klimek
              Hi Nancy, ... I m curious: why did you have to adapt C code for arm? Isn t it a normal 32-bit processor? We re running our unit test suite in CppUnit on
              Message 6 of 19 , Jan 27, 2008
              • 0 Attachment
                Hi Nancy,

                On Jan 27, 2008 1:48 PM, Nancy Van Schooenderwoert <vanschoo@...> wrote:
                > I'd like to point out CATSRunner, as a C unit testing framework
                > especially written for use in embedded software. The original release is
                > adapted for the ARM 7 CPU

                I'm curious: why did you have to "adapt" C code for arm? Isn't it a
                "normal" 32-bit processor?
                We're running our unit test suite in CppUnit on the arm 7, too. We
                didn't have to change a single line...

                /Manuel

                > , i.e. you can run your tests on ARM 7 and on a
                > desktop PC. The idea is that the framework has a generic part and a part
                > that needs to run on whatever your target CPU is. Users can port it to
                > other target CPUs fairly simply. The work you'd do to port this is work
                > you must do anyway to hook up debugging on your target CPU.
                >
                > http://freshmeat.net/projects/catsrunner/
                >
                > The above link gives info about this. I helped write this framework. The
                > intent was to keep it all in C, to work for those unfamiliar with C++ or
                > Perl, etc.
                >
                > This is rather specialised, and I haven't heard of other test frameworks
                > that attempt to do the same - work in C, specifically for embedded
                > software development.
                >
                > - njv
                >
                > --
                > ----------------------------------------------------------
                > Nancy Van Schooenderwoert Leading edge Agile coaching
                > http://www.leanagilepartners.com
                >
                >
                > Hugo Garcia wrote:
                > > Hi
                > >
                > > C doesn't seem to have a "standard" library for unit testing like
                > > other languages.
                > >
                > > Which framework do you use?
                > >
                > > If you are a framework author/contributor then please compare and
                > > contrast if the other frameworks.
                > >
                > > Thank You in advance.
                > >
                > > -H
                > >
                >
                > [Non-text portions of this message have been removed]
                >
                >



                --
                http://klimek.box4.net
              • John Carter
                ... Note 1. It s more important to get started with unit testing than to confront the team with a large and hairy framework that takes time to learn. ie.
                Message 7 of 19 , Jan 27, 2008
                • 0 Attachment
                  On Thu, 24 Jan 2008, Hugo Garcia wrote:

                  > C doesn't seem to have a "standard" library for unit testing like
                  > other languages.
                  >
                  > Which framework do you use?
                  >
                  > If you are a framework author/contributor then please compare and
                  > contrast if the other frameworks.

                  Note 1. It's more important to get started with unit testing than to
                  confront the team with a large and hairy framework that takes time to
                  learn.

                  ie. Sometimes it's better to get just started with a simplest #define
                  assert and actually write a unit test or three.

                  Thereafter, you understand the need for some of the bells and whistle
                  on the fancy frameworks.

                  Note 2. Half the problem with C is legacy code. You need some way of
                  stubbing out dependencies on the Big Ball of Mud legacy code so you
                  unit test will at least run.

                  Note 3. Dynamic languages sort out the "which module must link to
                  what" problem automagically for you. With C the other half the puzzle
                  is coping with the rapidly shifting link dependencies as the tests and
                  main program evolve. (Especially if not all the team is committed to
                  test driven development.)

                  Hint: Control of the build environment is handy. Instead of using
                  "make" which doesn't really give you all that much you care about
                  anyway...knock up your own using a rich scripting language like Ruby
                  or Python.

                  John Carter Phone : (64)(3) 358 6639
                  Tait Electronics Fax : (64)(3) 359 4632
                  PO Box 1645 Christchurch Email : john.carter@...
                  New Zealand
                • James Grenning
                  We re using CppUTest for embedded C. CppUTest is an evolution of CppUnitLite. It is on source forge. It will be doing another release of it soon. It is easy
                  Message 8 of 19 , Jan 27, 2008
                  • 0 Attachment
                    We're using CppUTest for embedded C. CppUTest is an evolution of
                    CppUnitLite. It is on source forge. It will be doing another release
                    of it soon.

                    It is easy to set up
                    new test cases take only one step (CppUnit requires 3 edits per new
                    test case)
                    setup and teardown are supported
                    the test harness supports a pre and post test plug in.
                    - One of the uses is to check for memory leaks.
                    - Its also bee used to check that our stubbed mutexes are all
                    released by the end of a test
                    its being used on a number of different embedded products.
                    There is some special customization for symbian
                    It is written in C++, but we are using for both C and C++ tests

                    If you are doing embedded C you might want to ask your question on the
                    AgileEmbedded group.

                    James

                    ----------------------
                    James Grenning
                    www.renaissancesoftware.net
                    cell: 847-630-0998

                    --- In extremeprogramming@yahoogroups.com, "Hugo Garcia"
                    <hugo.a.garcia@...> wrote:
                    >
                    > Hi
                    >
                    > C doesn't seem to have a "standard" library for unit testing like
                    > other languages.
                    >
                    > Which framework do you use?
                    >
                    > If you are a framework author/contributor then please compare and
                    > contrast if the other frameworks.
                    >
                    > Thank You in advance.
                    >
                    > -H
                    >
                  • David Carlton
                    ... ? Make knows all about all sorts of handy dependency rules which are very well suited for C and its derivatives; I wouldn t dream of hand-rolling something
                    Message 9 of 19 , Jan 27, 2008
                    • 0 Attachment
                      On Mon, 28 Jan 2008 11:42:40 +1300 (NZDT), John Carter <john.carter@...> said:

                      > Hint: Control of the build environment is handy. Instead of using
                      > "make" which doesn't really give you all that much you care about
                      > anyway...knock up your own using a rich scripting language like Ruby
                      > or Python.

                      ? Make knows all about all sorts of handy dependency rules which are
                      very well suited for C and its derivatives; I wouldn't dream of
                      hand-rolling something else, if that's what you're suggesting. I
                      don't know what compiler the original poster is using, but GCC will
                      even spit out appropriate make dependencies, making it extremely easy
                      to write a safe, parallelizable Makefile for C code, in many common
                      situations.

                      David Carlton
                      carlton@...
                    • John Roth
                      You don t have to roll your own. Ruby has Rake, and Python has SCons. They re both purpose built frameworks for doing builds. John Roth ... From: David
                      Message 10 of 19 , Jan 27, 2008
                      • 0 Attachment
                        You don't have to roll your own. Ruby has Rake,
                        and Python has SCons. They're both purpose built
                        frameworks for doing builds.

                        John Roth
                        ----- Original Message -----
                        From: "David Carlton" <carlton@...>
                        To: <extremeprogramming@yahoogroups.com>
                        Sent: Sunday, January 27, 2008 9:21 PM
                        Subject: Re: [XP] Group vote for C unit testing framework


                        > On Mon, 28 Jan 2008 11:42:40 +1300 (NZDT), John Carter
                        > <john.carter@...> said:
                        >
                        >> Hint: Control of the build environment is handy. Instead of using
                        >> "make" which doesn't really give you all that much you care about
                        >> anyway...knock up your own using a rich scripting language like Ruby
                        >> or Python.
                        >
                        > ? Make knows all about all sorts of handy dependency rules which are
                        > very well suited for C and its derivatives; I wouldn't dream of
                        > hand-rolling something else, if that's what you're suggesting. I
                        > don't know what compiler the original poster is using, but GCC will
                        > even spit out appropriate make dependencies, making it extremely easy
                        > to write a safe, parallelizable Makefile for C code, in many common
                        > situations.
                        >
                        > David Carlton
                        > carlton@...
                        >
                      • John Carter
                        ... Actually every large commercial make file I ve seen has been about 20% make and a mish-mash of shell, awk, grep and other darker things (eg. .bat) for the
                        Message 11 of 19 , Jan 28, 2008
                        • 0 Attachment
                          On Sun, 27 Jan 2008, David Carlton wrote:

                          > On Mon, 28 Jan 2008 11:42:40 +1300 (NZDT), John Carter <john.carter@...> said:
                          >
                          >> Hint: Control of the build environment is handy. Instead of using
                          >> "make" which doesn't really give you all that much you care about
                          >> anyway...knock up your own using a rich scripting language like Ruby
                          >> or Python.
                          >
                          > ? Make knows all about all sorts of handy dependency rules which are
                          > very well suited for C and its derivatives; I wouldn't dream of
                          > hand-rolling something else, if that's what you're suggesting. I
                          > don't know what compiler the original poster is using, but GCC will
                          > even spit out appropriate make dependencies, making it extremely easy
                          > to write a safe, parallelizable Makefile for C code, in many common
                          > situations.

                          Actually every large commercial make file I've seen has been about 20%
                          make and a mish-mash of shell, awk, grep and other darker things
                          (eg. .bat) for the rest. Trying to work out the various levels of
                          quote stripping between make,shell and awk can be entertaining at the
                          least!

                          So if a standard library module gives you that 20% that make gives
                          you.... why not do it all in a single excellently designed scripting
                          language.

                          I've done large build systems in both, and I can promise you the next
                          large build system I do will use a scripting language again.

                          John Carter Phone : (64)(3) 358 6639
                          Tait Electronics Fax : (64)(3) 359 4632
                          PO Box 1645 Christchurch Email : john.carter@...
                          New Zealand
                        • David Carlton
                          ... To give a bit more context, I m rather fond of make, and part of the reason why I m fond is that I ve spent time taking crap Makefiles and turning them
                          Message 12 of 19 , Jan 28, 2008
                          • 0 Attachment
                            On Tue, 29 Jan 2008 09:06:08 +1300 (NZDT), John Carter <john.carter@...> said:
                            > On Sun, 27 Jan 2008, David Carlton wrote:
                            >> On Mon, 28 Jan 2008 11:42:40 +1300 (NZDT), John Carter <john.carter@...> said:

                            >>> Hint: Control of the build environment is handy. Instead of using
                            >>> "make" which doesn't really give you all that much you care about
                            >>> anyway...knock up your own using a rich scripting language like Ruby
                            >>> or Python.
                            >>
                            >> ? Make knows all about all sorts of handy dependency rules which are
                            >> very well suited for C and its derivatives; I wouldn't dream of
                            >> hand-rolling something else, if that's what you're suggesting. I
                            >> don't know what compiler the original poster is using, but GCC will
                            >> even spit out appropriate make dependencies, making it extremely easy
                            >> to write a safe, parallelizable Makefile for C code, in many common
                            >> situations.

                            > Actually every large commercial make file I've seen has been about
                            > 20% make and a mish-mash of shell, awk, grep and other darker things
                            > (eg. .bat) for the rest. Trying to work out the various levels of
                            > quote stripping between make,shell and awk can be entertaining at
                            > the least!

                            To give a bit more context, I'm rather fond of make, and part of the
                            reason why I'm fond is that I've spent time taking crap Makefiles and
                            turning them into Makefiles that are shorter, have fewer bugs, and are
                            more parallelizable. (With help from gcc -MD -MP and ideas in
                            <http://make.paulandlesley.org/autodep.html>.) At the core, it seems
                            to be a reasonable language for handling dependencies in a way that
                            can easily handle typical tasks for C and its derivatives on Unix
                            systems, which happens to be a situation where I spend some amount of
                            time.

                            And, to give a bit more context, the only other build language that
                            I've used is ant (for a Java project); as far as I can tell, it gets
                            dependencies wrong, which I'd previously assumed was the single core
                            competency of anything that would call itself a build language. I
                            still tentatively assume that I must be missing something big there,
                            but I'm still a bit jaundiced towards other solutions. :-)

                            Having said that, I should look at rake and scons; I agree that, all
                            else being equal, I'd like my build system to be integrated with a
                            pleasant scripting language, and make isn't that.

                            John Roth mentioned rake and scons. Looking at the online
                            documentation, though, rake doesn't seem to be anywhere near ready for
                            prime time for C programming: I don't see any discussion of C issues,
                            and running "rake --help" doesn't mention anything about
                            parallelization, which would be an absolute show-stopper for me.

                            scons looks more interesting, though: it looks rather more
                            fully-featured, the man page mentions parallelization, so it would
                            probably work. I don't know for sure if it will get automatic
                            dependency generation completely right, but it might, and even if it
                            doesn't, it might be close enough that its other virtues outweigh that
                            drawback. I would certainly play around with it, and (if the results
                            were good) it would be quite natural to use it if there was enough
                            Python knowledge on the project. (Or maybe even if there wasn't -
                            it's not like make gurus are falling off of every tree, after all.)

                            David Carlton
                            carlton@...
                          • John Carter
                            ... Actually I find make a fairly nifty way of doing goal directed programming . Break up a task that takes a huge amount of real time into lots of small
                            Message 13 of 19 , Jan 28, 2008
                            • 0 Attachment
                              On Mon, 28 Jan 2008, David Carlton wrote:

                              > On Tue, 29 Jan 2008 09:06:08 +1300 (NZDT), John Carter <john.carter@...> said:
                              >> On Sun, 27 Jan 2008, David Carlton wrote:
                              >>> On Mon, 28 Jan 2008 11:42:40 +1300 (NZDT), John Carter <john.carter@...> said:
                              >
                              >>>> Hint: Control of the build environment is handy. Instead of using
                              >>>> "make" which doesn't really give you all that much you care about
                              >>>> anyway...knock up your own using a rich scripting language like Ruby
                              >>>> or Python.
                              >>>
                              > To give a bit more context, I'm rather fond of make, and part of the
                              > reason why I'm fond is that I've spent time taking crap Makefiles and
                              > turning them into Makefiles that are shorter, have fewer bugs, and are
                              > more parallelizable. (With help from gcc -MD -MP and ideas in
                              > <http://make.paulandlesley.org/autodep.html>.) At the core, it seems
                              > to be a reasonable language for handling dependencies in a way that
                              > can easily handle typical tasks for C and its derivatives on Unix
                              > systems, which happens to be a situation where I spend some amount of
                              > time.

                              Actually I find "make" a fairly nifty way of doing "goal directed
                              programming". Break up a task that takes a huge amount of real time
                              into lots of small chunks that persist individual step results to
                              disk. Let make sort out which step needs to be done / rerun next / in
                              parallel.

                              I did that once for a very large task, done it a couple more times for
                              several small tasks. But these days as soon as the problem begins to
                              grow I chuck the makefile and use Ruby and something like the ruby
                              "tsort" module.

                              Scripting language regex engines these days are quite amazingly
                              fast. ie. I can calculate the #include dependency 'net on the
                              fly. Admittedly I make one small simplifying assumption...

                              I don't preprocess C so I ignore #if's so if something goes...
                              #if 0
                              #include "fred.h"
                              #endif
                              my magic says (incorrectly) it depends on fred.h

                              Turns out it has been a small sacrifice that enables extracting the
                              dependency 'net on _every_ build. ie. You never have to remember to
                              "make depend" and you can get the dependency 'net exactly right (apart
                              from that small simplification) every build. (I _know_ from experience
                              that has saved me countless, "John your dependency tracking is wrong"
                              groundless complaints.

                              > Having said that, I should look at rake and scons; I agree that, all
                              > else being equal, I'd like my build system to be integrated with a
                              > pleasant scripting language, and make isn't that.
                              >
                              > John Roth mentioned rake and scons. Looking at the online
                              > documentation, though, rake doesn't seem to be anywhere near ready for
                              > prime time for C programming: I don't see any discussion of C issues,
                              > and running "rake --help" doesn't mention anything about
                              > parallelization, which would be an absolute show-stopper for me.

                              I chose to spin my own parallelization part for various reasons. No
                              biggy, took 24 lines of Ruby total. I bet I could do a simpler one in
                              less.

                              Leaping back onto the Subject Line Topic again...

                              But the best value from the whole exercise is a developer merely has
                              to specified which .o contains the "main" routine.

                              Then I use the exact same dependency tracking magic to go from a list
                              of defined and undefined symbols in the object files (generated by the
                              gcc/binutils "nm --extern" program) to a minimal list of object files
                              to feed to the linker to create an executable.

                              If the dependency net changes, no problem, it's all autogenerated.

                              Furthermore I can tweak that depending on whether I'm building a unit
                              test (present appropriate mocks to linker) or the real thing (guarantee no test
                              code ever)

                              Additional very nice things is I can catch and block bad practices (as
                              agreed on by the team) like cyclic dependencies in #include 'nets,
                              debug logging symbols in release builds, architectural layer smashing,
                              etc. etc. (I also provide (noisy) back doors on these blocks to allow
                              quick hack spike activity)




                              John Carter Phone : (64)(3) 358 6639
                              Tait Electronics Fax : (64)(3) 359 4632
                              PO Box 1645 Christchurch Email : john.carter@...
                              New Zealand
                            • David Carlton
                              ... Yeah, separate make depend steps are bad. ... Interesting, that s really cool! I ll have to keep that in my bag of tricks for the future. (Random trivia
                              Message 14 of 19 , Jan 28, 2008
                              • 0 Attachment
                                On Tue, 29 Jan 2008 11:23:49 +1300 (NZDT), John Carter <john.carter@...> said:

                                > Turns out it has been a small sacrifice that enables extracting the
                                > dependency 'net on _every_ build. ie. You never have to remember to
                                > "make depend" and you can get the dependency 'net exactly right (apart
                                > from that small simplification) every build. (I _know_ from experience
                                > that has saved me countless, "John your dependency tracking is wrong"
                                > groundless complaints.

                                Yeah, separate 'make depend' steps are bad.

                                > Then I use the exact same dependency tracking magic to go from a list
                                > of defined and undefined symbols in the object files (generated by the
                                > gcc/binutils "nm --extern" program) to a minimal list of object files
                                > to feed to the linker to create an executable.

                                > If the dependency net changes, no problem, it's all autogenerated.

                                > Furthermore I can tweak that depending on whether I'm building a
                                > unit test (present appropriate mocks to linker) or the real thing
                                > (guarantee no test code ever)

                                > Additional very nice things is I can catch and block bad practices (as
                                > agreed on by the team) like cyclic dependencies in #include 'nets,
                                > debug logging symbols in release builds, architectural layer smashing,
                                > etc. etc. (I also provide (noisy) back doors on these blocks to allow
                                > quick hack spike activity)

                                Interesting, that's really cool! I'll have to keep that in my bag of
                                tricks for the future.

                                (Random trivia for build geeks: if you don't want to do dependencies
                                every time, there's one correct time to do it: if you generate your
                                dependencies exactly when you compile the file, then you'll always
                                have your dependencies up to date without doing any more work than
                                necessary. That might work with some of your other suggestions, but
                                probably not all of them.)

                                David Carlton
                                carlton@...
                              • stephendicks
                                ... I finally got around to using Scons last year. Try it - you will never go back to make again. The only drawback(s) that I ve found so far are: Scons
                                Message 15 of 19 , Jan 29, 2008
                                • 0 Attachment
                                  --- In extremeprogramming@yahoogroups.com, David Carlton <carlton@...>
                                  wrote:
                                  >
                                  > On Tue, 29 Jan 2008 09:06:08 +1300 (NZDT), John Carter
                                  <john.carter@...> said:
                                  > > On Sun, 27 Jan 2008, David Carlton wrote:
                                  > >> On Mon, 28 Jan 2008 11:42:40 +1300 (NZDT), John Carter
                                  <john.carter@...> said:
                                  >
                                  > >>> Hint: Control of the build environment is handy. Instead of using
                                  > >>> "make" which doesn't really give you all that much you care about
                                  > >>> anyway...knock up your own using a rich scripting language like Ruby
                                  > >>> or Python.
                                  > >>
                                  > >> ? Make knows all about all sorts of handy dependency rules which are
                                  > >> very well suited for C and its derivatives; I wouldn't dream of
                                  > >> hand-rolling something else, if that's what you're suggesting. I
                                  > >> don't know what compiler the original poster is using, but GCC will
                                  > >> even spit out appropriate make dependencies, making it extremely easy
                                  > >> to write a safe, parallelizable Makefile for C code, in many common
                                  > >> situations.
                                  >
                                  > > Actually every large commercial make file I've seen has been about
                                  > > 20% make and a mish-mash of shell, awk, grep and other darker things
                                  > > (eg. .bat) for the rest. Trying to work out the various levels of
                                  > > quote stripping between make,shell and awk can be entertaining at
                                  > > the least!
                                  >
                                  > To give a bit more context, I'm rather fond of make, and part of the
                                  > reason why I'm fond is that I've spent time taking crap Makefiles and
                                  > turning them into Makefiles that are shorter, have fewer bugs, and are
                                  > more parallelizable. (With help from gcc -MD -MP and ideas in
                                  > <http://make.paulandlesley.org/autodep.html>.) At the core, it seems
                                  > to be a reasonable language for handling dependencies in a way that
                                  > can easily handle typical tasks for C and its derivatives on Unix
                                  > systems, which happens to be a situation where I spend some amount of
                                  > time.
                                  >
                                  > And, to give a bit more context, the only other build language that
                                  > I've used is ant (for a Java project); as far as I can tell, it gets
                                  > dependencies wrong, which I'd previously assumed was the single core
                                  > competency of anything that would call itself a build language. I
                                  > still tentatively assume that I must be missing something big there,
                                  > but I'm still a bit jaundiced towards other solutions. :-)
                                  >
                                  > Having said that, I should look at rake and scons; I agree that, all
                                  > else being equal, I'd like my build system to be integrated with a
                                  > pleasant scripting language, and make isn't that.
                                  >
                                  > John Roth mentioned rake and scons. Looking at the online
                                  > documentation, though, rake doesn't seem to be anywhere near ready for
                                  > prime time for C programming: I don't see any discussion of C issues,
                                  > and running "rake --help" doesn't mention anything about
                                  > parallelization, which would be an absolute show-stopper for me.
                                  >
                                  > scons looks more interesting, though: it looks rather more
                                  > fully-featured, the man page mentions parallelization, so it would
                                  > probably work. I don't know for sure if it will get automatic
                                  > dependency generation completely right, but it might, and even if it
                                  > doesn't, it might be close enough that its other virtues outweigh that
                                  > drawback. I would certainly play around with it, and (if the results
                                  > were good) it would be quite natural to use it if there was enough
                                  > Python knowledge on the project. (Or maybe even if there wasn't -
                                  > it's not like make gurus are falling off of every tree, after all.)

                                  I finally 'got around' to using Scons last year. Try it - you will
                                  never go back to 'make' again. The only drawback(s) that I've found so
                                  far are:

                                  Scons scripts are fully-fledged programs, so they can become overly
                                  complex (certainly my first attempts needed some refactoring, and my
                                  2nd and 3rd ones were improvements on the 1st).

                                  It is 'only' a build tool - you cannot trivially (at least I couldnt
                                  work it out) how to emulate 'make test' type behaviour where the tests
                                  are built and then run - I still used 'make' as a trivial controller.

                                  The documentation suggests a 'copy and build' approach, which works
                                  fine but can be confusing if you get a syntax error, as the 'compiled'
                                  source is a 'copy' (a writable copy at that) which should not of
                                  course be edited. [This style is not compulsory - a colleague used it
                                  by following the documentation]


                                  >
                                  > David Carlton
                                  > carlton@...
                                  >
                                • linux_tim
                                  Well to be fair cppunit takes only two if you don t write a header file. And why should you write a header that nobody will ever #include? ... From: James
                                  Message 16 of 19 , Feb 2, 2008
                                  • 0 Attachment
                                    Well to be fair cppunit takes only two if you don't write a header file. And why should you write a header that nobody will ever #include?


                                    -----Original Message-----
                                    From: James Grenning <james@...>
                                    Sent: January 27, 2008 7:26 PM
                                    To: extremeprogramming@yahoogroups.com
                                    Subject: [XP] Re: Group vote for C unit testing framework

                                    We're using CppUTest for embedded C. CppUTest is an evolution of
                                    CppUnitLite. It is on source forge. It will be doing another release
                                    of it soon.

                                    It is easy to set up
                                    new test cases take only one step (CppUnit requires 3 edits per new
                                    test case)
                                    setup and teardown are supported
                                    the test harness supports a pre and post test plug in.
                                    - One of the uses is to check for memory leaks.
                                    - Its also bee used to check that our stubbed mutexes are all
                                    released by the end of a test
                                    its being used on a number of different embedded products.
                                    There is some special customization for symbian
                                    It is written in C++, but we are using for both C and C++ tests

                                    If you are doing embedded C you might want to ask your question on the
                                    AgileEmbedded group.

                                    James

                                    ----------------------
                                    James Grenning
                                    www.renaissancesoftware.net
                                    cell: 847-630-0998

                                    --- In extremeprogramming@yahoogroups.com, "Hugo Garcia"
                                    <hugo.a.garcia@...> wrote:
                                    >
                                    > Hi
                                    >
                                    > C doesn't seem to have a "standard" library for unit testing like
                                    > other languages.
                                    >
                                    > Which framework do you use?
                                    >
                                    > If you are a framework author/contributor then please compare and
                                    > contrast if the other frameworks.
                                    >
                                    > Thank You in advance.
                                    >
                                    > -H
                                    >




                                    To Post a message, send it to: extremeprogramming@...

                                    To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

                                    ad-free courtesy of objectmentor.com
                                    Yahoo! Groups Links
                                  • Ray Tayek
                                    ... i was teaching a class on managed c++/c++/CLI a while ago. a managed c++ object is a subclass of system.object, so you can write the tests in nunit using
                                    Message 17 of 19 , Feb 3, 2008
                                    • 0 Attachment
                                      At 07:17 PM 1/25/2008, you wrote:
                                      >CppUnit, CppUnitLite, CppUTest, TUT, unit++.

                                      i was teaching a class on managed c++/c++/CLI a while ago. a managed
                                      c++ object is a subclass of system.object, so you can write the tests
                                      in nunit using the attributes which is fairly painless. you can use
                                      this to test pure c or c++ code if you can figure out how to get your
                                      code to be tested in the right kind of dll/assembly.

                                      thanks

                                      ---
                                      vice-chair http://ocjug.org/
                                    • Tim Ottinger
                                      By the way, I posted VIM macros quite a while back so that you don t even have to scroll to the top of the file to register your functions. I don t have to
                                      Message 18 of 19 , Feb 4, 2008
                                      • 0 Attachment
                                        By the way, I posted VIM macros quite a while back so that you don't even have to scroll to the top of the file to register your functions.
                                        I don't have to muck about three times in three places. I have only two places (no .h file) and the editor handles one of them.

                                        http://blog.objectmentor.com/articles/2007/05/03/cppunit-and-vim

                                        example:
                                        -----------------------------

                                        //////////////////////////////////////////////////////////////////////////////
                                        // testRecordParser.cc
                                        //////////////////////////////////////////////////////////////////////////////
                                        #include <iostream>
                                        #include <fstream>
                                        #include <string>
                                        #include <list>
                                        using namespace std;
                                        #include <cppunit/TestFixture.h>
                                        #include "cppunit/extensions/HelperMacros.h"

                                        #include "RecordParser.hh"


                                        class EmptyStringToParse: public CPPUNIT_NS::TestFixture {

                                        CPPUNIT_TEST_SUITE(EmptyStringToParse);
                                        CPPUNIT_TEST(eatWhiteSpaceDoesntCrash);
                                        CPPUNIT_TEST(returnWordDoesntDie);
                                        CPPUNIT_TEST(returnQuotedStringDoesntDie);
                                        CPPUNIT_TEST(parserKnowsItIsEmpty);
                                        CPPUNIT_TEST_SUITE_END();

                                        RecordParser *parser;
                                        public:
                                        void setUp() {
                                        parser = new RecordParser("");
                                        }
                                        void tearDown() {
                                        delete parser;
                                        }
                                        protected:
                                        void eatWhiteSpaceDoesntCrash() {
                                        parser->eatWhiteSpace();
                                        }
                                        void returnWordDoesntDie() {
                                        CPPUNIT_ASSERT_EQUAL(string(""), parser->returnWord());
                                        }
                                        void returnQuotedStringDoesntDie() {
                                        CPPUNIT_ASSERT_EQUAL(parser->returnQuotedString(),string(""));
                                        }
                                        void parserKnowsItIsEmpty() {
                                        CPPUNIT_ASSERT_EQUAL(true, parser->isEmpty() );
                                        }
                                        };
                                        CPPUNIT_TEST_SUITE_REGISTRATION(EmptyStringToParse);


                                        class UnquotedStringsForInput: public CPPUNIT_NS::TestFixture {
                                        CPPUNIT_TEST_SUITE(UnquotedStringsForInput);
                                        CPPUNIT_TEST(isNotConsideredEmpty);
                                        CPPUNIT_TEST(getsCorrectFirstWord);
                                        CPPUNIT_TEST(getsNoQuotedString);
                                        CPPUNIT_TEST_SUITE_END();

                                        RecordParser* parser;
                                        public:
                                        void setUp() {
                                        parser= new RecordParser("unquoted string");
                                        }
                                        void tearDown() {
                                        delete parser;
                                        }
                                        private:

                                        void isNotConsideredEmpty() {
                                        CPPUNIT_ASSERT_EQUAL(parser->isEmpty(), false);
                                        }

                                        void getsCorrectFirstWord() {
                                        string expected("unquoted");
                                        string actual = parser->returnWord();
                                        CPPUNIT_ASSERT_EQUAL(actual,expected);
                                        }
                                        void getsNoQuotedString() {
                                        string expected = "";
                                        string actual = parser->returnQuotedString();
                                        CPPUNIT_ASSERT_EQUAL(actual,expected);
                                        }
                                        };
                                        CPPUNIT_TEST_SUITE_REGISTRATION(UnquotedStringsForInput);


                                        ... and on and on we go....







                                        ____________________________________________________________________________________
                                        Looking for last minute shopping deals?
                                        Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

                                        [Non-text portions of this message have been removed]
                                      • John A. De Goes
                                        UnitTest++ is far superior to any other C++ unit testing framework I ve looked at. A simple examples suffices: // test.cpp #include
                                        Message 19 of 19 , Feb 4, 2008
                                        • 0 Attachment
                                          UnitTest++ is far superior to any other C++ unit testing framework
                                          I've looked at. A simple examples suffices:

                                          // test.cpp
                                          #include <UnitTest++.h>

                                          TEST(FailSpectacularly)
                                          {
                                          CHECK(false);
                                          }

                                          int main()
                                          {
                                          return UnitTest::RunAllTests();
                                          }

                                          Suites and fixtures are supported and are as lightweight as the above.

                                          John A. De Goes
                                          N-BRAIN, Inc.
                                          http://www.n-brain.net
                                          [n minds are better than n-1]

                                          On Feb 4, 2008, at 10:24 AM, Tim Ottinger wrote:

                                          > By the way, I posted VIM macros quite a while back so that you don't
                                          > even have to scroll to the top of the file to register your functions.
                                          > I don't have to muck about three times in three places. I have only
                                          > two places (no .h file) and the editor handles one of them.
                                          >
                                          > http://blog.objectmentor.com/articles/2007/05/03/cppunit-and-vim
                                          >
                                          > example:
                                          > -----------------------------
                                          >
                                          > //////////////////////////////////////////////////////////////////////////////
                                          > // testRecordParser.cc
                                          > //////////////////////////////////////////////////////////////////////////////
                                          > #include <iostream>
                                          > #include <fstream>
                                          > #include <string>
                                          > #include <list>
                                          > using namespace std;
                                          > #include <cppunit/TestFixture.h>
                                          > #include "cppunit/extensions/HelperMacros.h"
                                          >
                                          > #include "RecordParser.hh"
                                          >
                                          > class EmptyStringToParse: public CPPUNIT_NS::TestFixture {
                                          >
                                          > CPPUNIT_TEST_SUITE(EmptyStringToParse);
                                          > CPPUNIT_TEST(eatWhiteSpaceDoesntCrash);
                                          > CPPUNIT_TEST(returnWordDoesntDie);
                                          > CPPUNIT_TEST(returnQuotedStringDoesntDie);
                                          > CPPUNIT_TEST(parserKnowsItIsEmpty);
                                          > CPPUNIT_TEST_SUITE_END();
                                          >
                                          > RecordParser *parser;
                                          > public:
                                          > void setUp() {
                                          > parser = new RecordParser("");
                                          > }
                                          > void tearDown() {
                                          > delete parser;
                                          > }
                                          > protected:
                                          > void eatWhiteSpaceDoesntCrash() {
                                          > parser->eatWhiteSpace();
                                          > }
                                          > void returnWordDoesntDie() {
                                          > CPPUNIT_ASSERT_EQUAL(string(""), parser->returnWord());
                                          > }
                                          > void returnQuotedStringDoesntDie() {
                                          > CPPUNIT_ASSERT_EQUAL(parser->returnQuotedString(),string(""));
                                          > }
                                          > void parserKnowsItIsEmpty() {
                                          > CPPUNIT_ASSERT_EQUAL(true, parser->isEmpty() );
                                          > }
                                          > };
                                          > CPPUNIT_TEST_SUITE_REGISTRATION(EmptyStringToParse);
                                          >
                                          > class UnquotedStringsForInput: public CPPUNIT_NS::TestFixture {
                                          > CPPUNIT_TEST_SUITE(UnquotedStringsForInput);
                                          > CPPUNIT_TEST(isNotConsideredEmpty);
                                          > CPPUNIT_TEST(getsCorrectFirstWord);
                                          > CPPUNIT_TEST(getsNoQuotedString);
                                          > CPPUNIT_TEST_SUITE_END();
                                          >
                                          > RecordParser* parser;
                                          > public:
                                          > void setUp() {
                                          > parser= new RecordParser("unquoted string");
                                          > }
                                          > void tearDown() {
                                          > delete parser;
                                          > }
                                          > private:
                                          >
                                          > void isNotConsideredEmpty() {
                                          > CPPUNIT_ASSERT_EQUAL(parser->isEmpty(), false);
                                          > }
                                          >
                                          > void getsCorrectFirstWord() {
                                          > string expected("unquoted");
                                          > string actual = parser->returnWord();
                                          > CPPUNIT_ASSERT_EQUAL(actual,expected);
                                          > }
                                          > void getsNoQuotedString() {
                                          > string expected = "";
                                          > string actual = parser->returnQuotedString();
                                          > CPPUNIT_ASSERT_EQUAL(actual,expected);
                                          > }
                                          > };
                                          > CPPUNIT_TEST_SUITE_REGISTRATION(UnquotedStringsForInput);
                                          >
                                          > ... and on and on we go....
                                          >
                                        Your message has been successfully submitted and would be delivered to recipients shortly.