Home > Archive > Extreme Programming > August 2005 > CPP Unit : Does it worth the time?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
CPP Unit : Does it worth the time?
|
|
| varuna82lk@gmail.com 2005-08-26, 6:57 pm |
| I am a newbie to CPP Unit. When I studie it it seems to me like it
doesn't worth the time and resources spend on it. If you think it's
worth using in comercial projects. Why?
Thank you.
Varuna.
| |
|
| varuna82lk wrote:
> I am a newbie to CPP Unit. When I studie it it seems to me like it
> doesn't worth the time and resources spend on it. If you think it's
> worth using in comercial projects. Why?
Are you asking about unit testing in general, or CppUnit itself?
When you write developer tests, and run them after every few edits, you can
trade many long hours debugging for a few short minutes writing tests. The
effect on scheduling is profound; you can easily estimate the time required
for new features. The estimates will not be affected by the risk of
occassional but very long bug hunts.
CppUnit has many powerful features that are difficult to learn to use. It
also has a difficult object model that tends to take over your environment.
C++ supports many alternatives because the root features are very easy to
code.
Use a unit test rig that supports the Test Collector pattern. That means you
don't need to write the name of each test case 2 to 4 times just to enrole
it into a test list. I prefer test rigs supporting this:
TEST_(TestSuite, myCase)
{
CHECK_EQUALS(42, myMethod());
}
That's all you need to write to add that block of code to the global test
list. CppUnitLite has that feature.
Next, when CHECK_EQUALS fails, the assertion should fire a breakpoint inside
this block, so the cursor hits that exact line that failed. (Some assertion
systems dump you deep inside their libraries, if at all...)
Now please report the specific problems you encounter, so we can overcome
them.
--
Phlip
[url]http://www.greencheese.org/Z Land[/url] <-- NOT a blog!!!
| |
| varuna82lk@gmail.com 2005-08-27, 6:56 pm |
| I think I need to study the CppUnit test more. Thank you for your
guidence. I just wanted to know whether it is worth spending time
learning it.
And one more thing. Does adding CppUnit makes the code size larger?
or
Does it effect the efficiency?
Thank you.
Varuna.
| |
|
| varuna82lk wrote:
> I think I need to study the CppUnit test more. Thank you for your
> guidence. I just wanted to know whether it is worth spending time
> learning it.
Read /Unit Test Frameworks/ by Paul Hamil, and /Test Driven Development/ by
Kent Beck.
There is no way to exaggerate the benefits of learning these techniques.
They will put you into a small group of elite programmers.
> And one more thing. Does adding CppUnit makes the code size larger?
> or Does it effect the efficiency?
No. You configure your code to compile in two configurations. (Most
compiling environments support Debug and Release, so just use those.)
The Debug build contains all assert() statements, compiles with debugging
information turned on, and conditionally compiles the tests. The Release
build compiles with all optimizations turn on, all assertion code turned
off, and all tests turned off. The resulting code is perfectly small and
efficient.
Further, programmers should not worry about efficiency until their code is
clean and bug-free. Once it is, they can easily optimize if they have a
complete test suite to run after each tiny change. So using unit tests will
in turn permit you to aggressively optimize your code.
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| varuna82lk@gmail.com 2005-08-27, 9:57 pm |
| Thank you very much. If I get into trouble I will refer you for sure.
Thank you.
Varuna.
| |
| lilburne 2005-08-30, 6:57 pm |
| Phlip wrote:
> varuna82lk wrote:
>
>
>
>
> Read /Unit Test Frameworks/ by Paul Hamil, and /Test Driven Development/ by
> Kent Beck.
>
> There is no way to exaggerate the benefits of learning these techniques.
> They will put you into a small group of elite programmers.
>
>
>
>
> No. You configure your code to compile in two configurations. (Most
> compiling environments support Debug and Release, so just use those.)
>
> The Debug build contains all assert() statements, compiles with debugging
> information turned on, and conditionally compiles the tests. The Release
> build compiles with all optimizations turn on, all assertion code turned
> off, and all tests turned off. The resulting code is perfectly small and
> efficient.
>
Eh! All tests should be run in release otherwise how do you know that
you've tested the code that being shipped? Sometimes the buggers put
side-affects into asserts and debug code. Running the tests in release
weedles them out. In addition the optimizer can screw up big time.
| |
| Hang Dog 2005-08-31, 3:57 am |
|
Phlip wrote:
>
> So the Final mode is obviously the release candidate image, and the Metrics
> mode is sufficiently accessible to tests that they can collect performance
> data.
>
> All configurations run with optional logging levels, per module if needed.
> But the closer to final, the fewer logging statements are conditionally
> compiled in.
>
Better that sort of maps to our devdbg, devndb, reldbg, and relndb builds.
|
|
|
|
|