By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,538 Members | 2,225 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,538 IT Pros & Developers. It's quick & easy.

Testing in C++

P: n/a
nw
Hi,

I have been asked to teach a short course on testing in C++. Until now
I have used my own testing classes (which from what I've seen seem
similar to the boost unit testing classes). Considering I have a
limited amount of time what do readers of this group think would be
useful to cover in this course? Is boost the way to go?

Sorry if this is off-topic in this group.

Many Thanks.

Mar 8 '07
Share this Question
Share on Google+
58 Replies


P: n/a
Pete Becker wrote:
Ian Collins wrote:
>>>
I think we are arguing at cross purposes here, what are tests run
against if not the original code?

Yes, sorry: by "the original code" I was referring to the failing code
submitted by the customer.
Ah, I see now, you were working with a compiler test suite.

--
Ian Collins.
Mar 9 '07 #51

P: n/a
Ian Collins wrote:
Pete Becker wrote:
>Ian Collins wrote:
>>I think we are arguing at cross purposes here, what are tests run
against if not the original code?
Yes, sorry: by "the original code" I was referring to the failing code
submitted by the customer.
Ah, I see now, you were working with a compiler test suite.
Whoops, sorry: you're right, that's why I fell into that terminology.
So: the customer's test case isn't necessarily the same as the test case
you end up writing when you make the fix. The latter will often be
smaller and faster.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Mar 9 '07 #52

P: n/a
Pete Becker wrote:
Noah Roberts wrote:
>>
In general, yes you can find the meaning of a phrase through analysis
of its composite words. If you couldn't communication would be
difficult if not impossible.

The meaning of modifiers is often determined by context, which a
dictionary doesn't understand. For example, if you look up "unit" in the
dictionary, its definition could lead you to believe that a "unit test"
is any test that you apply to your application, which is, after all, a
"unit".
How so? Since unit is quite explicitly singular and meaning a single
part and applications are composed of several distinct modules and
components. I imagine someone on the outside of development might fall
into a definition like that but those that understand what composes an
application shouldn't. The first time I heard the term there was little
doubt to its meaning; it was almost completely self explainitory.
Mar 9 '07 #53

P: n/a
Noah Roberts wrote:
Pete Becker wrote:
>Noah Roberts wrote:
>>>
In general, yes you can find the meaning of a phrase through analysis
of its composite words. If you couldn't communication would be
difficult if not impossible.

The meaning of modifiers is often determined by context, which a
dictionary doesn't understand. For example, if you look up "unit" in
the dictionary, its definition could lead you to believe that a "unit
test" is any test that you apply to your application, which is, after
all, a "unit".

How so? Since unit is quite explicitly singular and meaning a single
part and applications are composed of several distinct modules and
components. I imagine someone on the outside of development might fall
into a definition like that but those that understand what composes an
application shouldn't. The first time I heard the term there was little
doubt to its meaning; it was almost completely self explainitory.
Okay, I gave you too much leeway, and you dodged the issue. So let me
say it again:

The definition of "unit" could lead you to believe that a "unit test" is
any test that you apply to any of the executables that constitute your
application.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
Mar 9 '07 #54

P: n/a
Pete Becker wrote:
Noah Roberts wrote:
>Pete Becker wrote:
>>Noah Roberts wrote:

In general, yes you can find the meaning of a phrase through
analysis of its composite words. If you couldn't communication
would be difficult if not impossible.

The meaning of modifiers is often determined by context, which a
dictionary doesn't understand. For example, if you look up "unit" in
the dictionary, its definition could lead you to believe that a "unit
test" is any test that you apply to your application, which is, after
all, a "unit".

How so? Since unit is quite explicitly singular and meaning a single
part and applications are composed of several distinct modules and
components. I imagine someone on the outside of development might fall
into a definition like that but those that understand what composes an
application shouldn't. The first time I heard the term there was
little doubt to its meaning; it was almost completely self explainitory.

Okay, I gave you too much leeway, and you dodged the issue. So let me
say it again:

The definition of "unit" could lead you to believe that a "unit test" is
any test that you apply to any of the executables that constitute your
application.
No, I didn't dodge the issue. I didn't say applications where composed
of several executables.

Yes, it could lead you to believe that unit test means test the whole
program but you would have to use an incomplete definition of unit and
have an incomplete knowledge of program development to fairly make that
assumption since unit quite explicitly means a single part and
applications are made up of several distinct pieces. I'm fairly certain
the first time you heard the phrase it didn't require a lot of
explanation either.
Mar 9 '07 #55

P: n/a
Noah Roberts wrote:
Yes, it could lead you to believe that unit test means test the whole
program but you would have to use an incomplete definition of unit
To avoid arguments over definitions, select definitions that are distinct,
useful, and concise. "Distinct" means that any two engineers could apply the
definition (whether or not they agree it is useful), and get the same
results.

For example, a good definition of a "unit test" is this: "A test whose
failure implicates a well-defined unit of the code, requiring very little
search to find the bug".

The definition applies to a process - a test failing - and not to a static
analysis of the test's code. The definition could include multiple
executables, if the test's failure is still easy to search out.

The point of the definition is not to achieve semiotic perfection, it is to
avoid excessive searching when a unit test fails.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Mar 10 '07 #56

P: n/a
Pete Becker wrote:
nw wrote:
>Hi,

I have been asked to teach a short course on testing in C++. Until now
I have used my own testing classes (which from what I've seen seem
similar to the boost unit testing classes). Considering I have a
limited amount of time what do readers of this group think would be
useful to cover in this course? Is boost the way to go?

Talk about testing, not about tools. For example, have each member of
the class write a complete set of test cases for a program that reads
three numbers from stdin and tells you whether a triangle with sides of
those lengths is equilateral, isosceles, scalene, or impossible. Then
compare the solutions, and talk about testing principles that help
refine the set of test cases.
Unit testing is merely one aspect of software testing, but it
probably merits a complete course on its own.

Because unit testing should be light in time to encourage its
use at build time, I mostly recommend not using a framework at
all. The unit test program merely needs to report success or
failure to the build environment, and should be silent on
successes and verbose on failures.

Legacy code needs careful treatment. Most beginning programmers
will need to deal with existing code in the real world. They
will need to know about breaking dependencies, creating mock
objects, and test coverage.

The limitations of unit testing should also be covered. Unit
tests at build time just don't do the same job as Monte Carlo
testing with randomized loads (useful for multi-threaded
testing), but you don't want to want every build for a million
trial MC run.

I like Michael Feather's book Working Effectively with Legacy
Code. It contains good material on unit testing for both new
code and legacy code.
Mar 11 '07 #57

P: n/a
Glen Dayton wrote:
Pete Becker wrote:
>nw wrote:
>>Hi,

I have been asked to teach a short course on testing in C++. Until now
I have used my own testing classes (which from what I've seen seem
similar to the boost unit testing classes). Considering I have a
limited amount of time what do readers of this group think would be
useful to cover in this course? Is boost the way to go?

Talk about testing, not about tools. For example, have each member of
the class write a complete set of test cases for a program that reads
three numbers from stdin and tells you whether a triangle with sides
of those lengths is equilateral, isosceles, scalene, or impossible.
Then compare the solutions, and talk about testing principles that
help refine the set of test cases.

Unit testing is merely one aspect of software testing, but it probably
merits a complete course on its own.

Because unit testing should be light in time to encourage its use at
build time, I mostly recommend not using a framework at all. The unit
test program merely needs to report success or failure to the build
environment, and should be silent on successes and verbose on failures.
Using a framework takes a lot of the donkey work out of writing unit
test suites. Most frameworks are silent on successes and verbose on
failures.

--
Ian Collins.
Mar 11 '07 #58

P: n/a
Glen Dayton wrote:
I like Michael Feather's book Working Effectively with Legacy Code. It
contains good material on unit testing for both new code and legacy code.
Yes, it's a very good book.
Mar 12 '07 #59

58 Replies

This discussion thread is closed

Replies have been disabled for this discussion.