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

C++ unit testing

P: n/a
I am looking for a C++ unit testing program. I googled and found there are
quite a few there, such as CppTest, C++Test, and DejaGnu. Can someone give
me a recommendation among these programs? I want to the software is easy to
use and has a nice interface. Please excuse me if it is out of the topic.

Thanks in advance!
Jul 22 '05 #1
Share this Question
Share on Google+
19 Replies


P: n/a
newbiecpp wrote:
I am looking for a C++ unit testing program. I googled and found there are
quite a few there, such as CppTest, C++Test, and DejaGnu. Can someone give
me a recommendation among these programs? I want to the software is easy to
use and has a nice interface. Please excuse me if it is out of the topic.


Look at "Austria C++" (shamless plug).

http://austria.sourceforge.net/
Jul 22 '05 #2

P: n/a
"newbiecpp" <ne*******@yahoo.com> wrote:
I am looking for a C++ unit testing program. I googled and found there are
quite a few there, such as CppTest, C++Test, and DejaGnu. Can someone give
me a recommendation among these programs? I want to the software is easy to
use and has a nice interface. Please excuse me if it is out of the topic.


Write one, but make sure you have unit tests to make sure it works. ;-)
Jul 22 '05 #3

P: n/a

"newbiecpp" <ne*******@yahoo.com> wrote in message
news:o44Zc.217$P97.69@trndny04...
I am looking for a C++ unit testing program. I googled and found there are
quite a few there, such as CppTest, C++Test, and DejaGnu. Can someone give
me a recommendation among these programs? I want to the software is easy to
use and has a nice interface. Please excuse me if it is out of the topic.


Take a look at the boost unit test framework: http://tinyurl.com/5kp6c.

Jonathan
Jul 22 '05 #4

P: n/a
newbiecpp wrote:
I am looking for a C++ unit testing program. I googled and found there are
quite a few there, such as CppTest, C++Test, and DejaGnu. Can someone give
me a recommendation among these programs? I want to the software is easy to
use and has a nice interface. Please excuse me if it is out of the topic.

Thanks in advance!

cppunit would be really useful.

If you had used JUnit (for Java platform) before, you would find this
really easy to start with.

http://sourceforge.net/projects/cppunit .

--
Karthik.
Jul 22 '05 #5

P: n/a
"newbiecpp" <ne*******@yahoo.com> wrote in message news:<o44Zc.217$P97.69@trndny04>...
I am looking for a C++ unit testing program. I googled and found there are
quite a few there, such as CppTest, C++Test, and DejaGnu. Can someone give
me a recommendation among these programs? I want to the software is easy to
use and has a nice interface. Please excuse me if it is out of the topic.

Thanks in advance!


CppUnit is my favourite. There is a nice CppUnit cookbook available
which gets you started with it very quicky. There is also CppUnitLite
which is simpler to learb than CppUnit because it has less no. of
features.
Jul 22 '05 #6

P: n/a
"newbiecpp" <ne*******@yahoo.com> wrote in message news:<o44Zc.217$P97.69@trndny04>...
I am looking for a C++ unit testing program. I googled and found there are
quite a few there, such as CppTest, C++Test, and DejaGnu. Can someone give
me a recommendation among these programs? I want to the software is easy to
use and has a nice interface. Please excuse me if it is out of the topic.

Thanks in advance!


I am currently using cxxtest.

http://cxxtest.sourceforge.net/

Good Luck

--
Marcelo Pinto
Jul 22 '05 #7

P: n/a
newbiecpp wrote:

I am looking for a C++ unit testing program. I googled and found there are
quite a few there, such as CppTest, C++Test, and DejaGnu. Can someone give
me a recommendation among these programs? I want to the software is easy to
use and has a nice interface. Please excuse me if it is out of the topic.

Thanks in advance!


Do you have the liberty to choose your language? If so, I'd recommend looking
at C# (and equivalent) were unit tests and story tests are much better
supported by the language.

In our C++ projects, we use CppTest, but we have since decided to re-write in
C#, and unit/story tests was one of the primary motivations.

Reflection (and attribute) support in the language proper *really* facilitates
unit test frameworks.
Jul 22 '05 #8

P: n/a
Julie wrote:
Do you have the liberty to choose your language? If so, I'd recommend
looking at C# (and equivalent) were unit tests and story tests are much
better supported by the language.
Story test is not a term I am familiar with. Can you please explain what
this means? If forced to guess, I might speculate that these are basically
use cases?
In our C++ projects, we use CppTest,
I gave up trying to compile CppTest for linux. I'm not sure why it's
failing, but it appears no to like my versions of autotools. I've also had
a bad time trying to use the boost test library. I believe all of these
problems are related to the failure of the C++ Standard to more clearly
define the relationship between the program and the implementation
environment. Or perhaps it would be better to say that the concept of a
translation unit, with its implicit assumption that header files and
#includes are involved, leads to these kinds of difficulties.

It's almost comical that I sent a message - actually a repost - with the
following:

//---from Message-ID:<EO********************@speakeasy.net> ---
Now a tricky thing that comes into play is the relationship between
declaration and definition.**I*have*to*admit*that*falls*into*the*c ategory
of religious faith for me.**Under*most*circumstances,*it*simply*works,*wh en
it doesn't I play with the environment variables, and linker options until
something good happens.
//------------- END excerpt ------------------------------------

And the next thing I did was try to use the boost test library which
resulted in errors telling me the linker was unable to resolve certain
symbols used in my (trivial) program. I know now that I can compile within
the boost source tree and these symbols resolve. I have yet to figure out
how and why this happens.

I say it's almost comical. The fact of the matter is that it is actually
sad. My background in IT is not primarily coding. For the most part, I've
done integration, highlevel design, configuration, troubleshooting,
hardware maintenance, etc.

<aside>
The fact of the matter is that my work in highlevel engineering left me
rather embarrassed and somewhat ashamed that I was more-or-less 'lording
over' programmers who IMO deserved more credit and recognition for their
work than I did for mine. I wasn't supervising them, but I was certainly
treated as if they were not as significant or valuable. I knew better.
</aside>

When studying computer science in college (while working fulltime) I was
inclined at one point to learn C++ as a focus. Unfortunately that wasn't
consistent with my current employment situation. I ended up focusing on
networking and system design. I did try to get some programming experience
when I could. Unfortunately, that usually resulted in 10% of my available
time being spent on actual coding, and the remainder spent on trying to
figure out what the particular library was not behaving as expected.

I've written code in perl, bash, JavaScript, C, Mathematica, POVRay, Java,
Icon, Ada, Lisp, and probably other languages I can't think of right now.
One advantage I get from having such diverse experience is that I have seen
how things are done in different languages, and on different platforms.
One of the most frightening results of my learning C++ - and this is really
difficult to explain - is that I now seem to understand Lisp much better
than I previously did. That may seem completely irrelevant to this
discussion, and to some extend it is. But it does offer a means of
introducing Emacs which is a huge exercise in self-inflicted Lisp.

I've mentioned this before. The first C implementation of Emacs was written
by James Gosling. That is the same James Gosling who created Java. It is
clear he employed many ideas from his Emacs experience when designing Java.
It's interesting to point out that Mathematica smells a whole lot like
Emacs and Lisp. Though they take very different approaches, Mathematica
and Java share some similarity in how they implemented libraries. One of
the most significant similarities is that both rely on the use of directory
names to locate packages by name. I'm not sure this is directly traceable
to Emacs, but it seems like a logical extension of the method used by Emacs
to integrate documentation and implementation in the Lisp code. As well as
the query mechanisms used to locate resources. Introspection seems like a
logical extension of that as well. That may, however, be attributable to
SmallTalk rather than Emacs Lisp.

What is important is not how it was accomplished, or even the details of
what was accomplished in these different cases. What is important is that
Emacs, Mathematica, and Java all use libraries which are selfdescribing,
and rely on clearly defined mechanisms for integrating libraries into the
programming environment. With C++ I am required to learn not one, but
often several languages in order to manages my compilation and integration.
For example, bjam has a language of its own. Makefiles use a very
simplistic language, and when used on any significantly large scale require
the use of automake, autoconf, aclocal, etc. This typically requires some
level of understanding of the syntax and semantics of the M4 macro language
as well as bash, or whatever other command interpreter you are using(e.g.,
DOS Shell).

It is simply an unreasonable burden to place on the programmer, and, AFAIK,
(almost) completely unnecessary. Sure there is Apache Ant which can be
used for building Java. Ant is far easier to learn than anything I've seen
for C++. For the most part, that is because the underlying mechanism is
more clearly defined, and simpler. There is no objective reason - that I
am aware of - preventing the same from being done with C++. I believe the
main reason it hasn't been done is that most C++ programmers have not
encountered the difficulties I'm describing. They simply do not work with
the extensive variety of tools and libraries I work with. They typically
use one particular IDE, and rely on it to manage their resources for them.

Since they have no extensive experience working with other programming
environments created for other languages, they do not appreciate the
advantages these tools can provide. When the strengths of these features
are pointed out as advantages these languages provide over C++ development
environments, the usual response from C++ programmers is to point out the
advantages C++ has over the other language, and to explicitly or implicitly
suggest that people who can't understand pointers and unchecked array
access are the only people who could benefit from these powerful features.
but we have since decided to re-write
in C#, and unit/story tests was one of the primary motivations.
Reflection (and attribute) support in the language proper *really*
facilitates unit test frameworks.


I see no fundamental reason that a C++ library (or better still an industry
guideline or standard) could not be created to support this functionality
as well as (other) introspective facilities. My own opinion is that C++
offers valuable features that these other languages lack. In C++ there is
far more fine-grained control over how program entities are manipulated,
and how they manipulate other program entities. I find the argument for
garbage collection rather weak now that I better understand the issue. C++
forces you to manage your resources well. For the most part, a program
that needs garbage collection is probably poorly designed. The use of
pointers and references is likewise something that promotes better
understanding of what you are actually doing.

The choice to leave built-in types, including pointers, uninitialized by
default was perhaps a bad choice. But there is no reason that I can see for
a compiler not to issue warnings when a pointer or arithmetic type variable
is not initialized. Better still, the IDE could detect this and indicate
it at edit-time. The biggest problem with C++ is not a fundamental problem
with the language. It is the failure to require the implementation to
resolve types to their point of definition based on language syntax and
semantics. If I were released from that responsibility, it would save me
the majority of time I spend working with C++. IOW, I spend more time
addressing infrastructure problems than I do writing code. Any time I try
to integrate a new library into my development environment, I can expect to
spend the better part of a day resolving issues related to configuration.

This is a major reason IDE support is so weak in C++. IDE developers have
to deal with the poorly defined and unpredictable nature of C++ library
management. Yes, C++ is a more complex language, and it isn't as easy to
parse as the others, but that isn't the problem. That challenge cannot be
addressed because of the obstacles presented by the #include mechanism.

--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.

Jul 22 '05 #9

P: n/a
In article <Y5********************@speakeasy.net>, Steven T. Hatton
<su******@setidava.kushan.aa> wrote:

Story test is not a term I am familiar with. Can you please explain what
this means? If forced to guess, I might speculate that these are basically
use cases?


I think you're right. It's a buzzword used by the Extreme Programming
brigade. Basically, it's customer acceptance testing.
Alwyn
Jul 22 '05 #10

P: n/a
"Steven T. Hatton" wrote:

Julie wrote:
Do you have the liberty to choose your language? If so, I'd recommend
looking at C# (and equivalent) were unit tests and story tests are much
better supported by the language.
Story test is not a term I am familiar with. Can you please explain what
this means? If forced to guess, I might speculate that these are basically
use cases?


Yes, story tests are formatted use cases. These are then fed into a test
framework that validates the outputs w/ the supplied inputs.

fit is the most popular (only?) framework under C#. Complete lack of details
can be found at the source website: http://fit.c2.com

Once you figure it out, it is a pretty powerful way for the customer (client or
chief architect) to specify expected behavior, and then using TDD, you build
off of it.

As was mentioned in another follow-up, this is part of XP (extreme
programming).
In our C++ projects, we use CppTest,


I gave up trying to compile CppTest for linux. I'm not sure why it's
failing, but it appears no to like my versions of autotools. I've also had


<snip: too long for me on a Friday>
Jul 22 '05 #11

P: n/a
Julie wrote:
"Steven T. Hatton" wrote:

Julie wrote:
> Do you have the liberty to choose your language? If so, I'd recommend
> looking at C# (and equivalent) were unit tests and story tests are much
> better supported by the language.


Story test is not a term I am familiar with. Can you please explain what
this means? If forced to guess, I might speculate that these are
basically use cases?


Yes, story tests are formatted use cases. These are then fed into a test
framework that validates the outputs w/ the supplied inputs.

fit is the most popular (only?) framework under C#. Complete lack of
details can be found at the source website: http://fit.c2.com

Once you figure it out, it is a pretty powerful way for the customer
(client or chief architect) to specify expected behavior, and then using
TDD, you build off of it.

As was mentioned in another follow-up, this is part of XP (extreme
programming).
> In our C++ projects, we use CppTest,


I gave up trying to compile CppTest for linux. I'm not sure why it's
failing, but it appears no to like my versions of autotools. I've also
had


<snip: too long for me on a Friday>


The upshot of it all is that there is nothing C# provides that couldn't be
accomplished with C++. The biggest reason these 'modern' features aren't
available is because #include statement gets in the way of progress.
--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.

Jul 22 '05 #12

P: n/a
In article <Y5********************@speakeasy.net>, Steven T. Hatton
<su******@setidava.kushan.aa> wrote:
Julie wrote:
Do you have the liberty to choose your language? If so, I'd recommend
looking at C# (and equivalent) were unit tests and story tests are much
better supported by the language.
Story test is not a term I am familiar with. Can you please explain what
this means? If forced to guess, I might speculate that these are basically
use cases?


I believe you are right. It's a term used by the Extreme Programming
brigade. I'm not clear, however, how C# could provide better support
for them than any other language, since they are essentially user
acceptance tests, i.e. tests of the behaviour of the system from a
user's perspective.

<snip>
When studying computer science in college (while working fulltime) I was
inclined at one point to learn C++ as a focus.
Well, they taught me Pascal in my first year, and I had to write a
compiler in it. That's discipline for you!

<snip>
This is a major reason IDE support is so weak in C++. IDE developers have
to deal with the poorly defined and unpredictable nature of C++ library
management.
Real programmers distrust IDEs. I fear they have nurtured a generation
of technophobic 'softies' addicted to point-and-click and eye-candy.
Give me Emacs and proper command-line tools any day!

<snip>
Yes, C++ is a more complex language, and it isn't as easy to
parse as the others, but that isn't the problem. That challenge cannot be
addressed because of the obstacles presented by the #include mechanism.


Well yes, the C-based languages are missing proper module support. We
all know that, and it ain't gonna change any time soon.

Anyway, over all, I thought your posting was a bit of a rant,
flamebait, even. It's just not good form to come to a C++ forum and
start lambasting the language from all directions. The people here have
chosen to learn C and C++ for various reasons, some good, some bad, no
doubt.
Alwyn
Jul 22 '05 #13

P: n/a
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message news:<E7********************@speakeasy.net>...

[ ... ]
The upshot of it all is that there is nothing C# provides that couldn't be
accomplished with C++. The biggest reason these 'modern' features aren't
available is because #include statement gets in the way of progress.


Would that #include statements were really the difficult part of
building tools for C++. Unfortunately, that's just not the case. I've
written quite a few tools that dealt with C++ source code, and
preprocessor directives were _never_ the difficult part of them.

The real difficulty stems from two facts: 1) parsing C++ is a
nightmare, and 2) even relatively simple tools need nearly a complete
parser. These both stem largely from the fact that you can't parse
C++ purely syntactically -- in many cases, you need to know whether
some name specifies a type or an object to determine what sort of
statement you're parsing. Just for an obvious and well-known example:

X y(z);

might be either a definition of an object named y of type X with an
initializer z, OR it might be a declaration of a function named y with
return type X and a single parameter of type z. You can't determine
the difference based on the syntax -- to make the determination, you
need to know whether 'z' signifies a type or (something that can be
converted to) an rvalue.

Unfortunately, all of this cascades as well, so you can't produce a
semi-usable tool by just skipping over a few tough cases -- a fairly
large number of cases are in the "tough" class, and things cascade
together so the type of the next statement might depend on the type of
this one.

All this boils down to the fact that you need to maintain a (fairly)
complete symbol table to be able to parse C++ at all. In fact, nearly
the only parts of a C++ file you CAN deal with using simple tools are
the preprocessor directives.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 22 '05 #14

P: n/a
Alwyn wrote:
Steven T. Hatton wrote:
Julie wrote:
Do you have the liberty to choose your language? If so, I'd recommend
looking at C# (and equivalent) were unit tests and story tests are much better supported by the language.
Story test is not a term I am familiar with. Can you please explain what this means? If forced to guess, I might speculate that these are basically use cases?


I believe you are right. It's a term used by the Extreme Programming
brigade.


Joshua Kerievsky uses "storytest" for his "Industrial XP" dialect, meaning a
"customer acceptance test that passes one user story".
I'm not clear, however, how C# could provide better support
for them than any other language, since they are essentially user
acceptance tests, i.e. tests of the behaviour of the system from a
user's perspective.
Because C# uses both reflection and those [code attribute] things. There are
those who have written acceptance test frameworks (hence "storytest"
frameworks) that leverage reflection as a very modest shortcut in authoring
new test fixtures. Because popular eXtremos pushed these frameworks,
everyone now thinks that reflection is somehow required for storytests.

If you want reflection, just use XML with all its attributes. Problem
solved.
<snip>
When studying computer science in college (while working fulltime) I was
inclined at one point to learn C++ as a focus.
Well, they taught me Pascal in my first year, and I had to write a
compiler in it. That's discipline for you!


Could they have taught "software engineering" instead of "computer science",
or would that have made their hands grubby?
<snip>
This is a major reason IDE support is so weak in C++. IDE developers have to deal with the poorly defined and unpredictable nature of C++ library
management.


Real programmers distrust IDEs. I fear they have nurtured a generation
of technophobic 'softies' addicted to point-and-click and eye-candy.
Give me Emacs and proper command-line tools any day!


A better strategy is to configure your IDE to compile and run all your tests
after one keystroke, then to make sure your programmer tests (not
storytests) grow features that make programming in the tests more productive
than programming in the debuggers, form painters, or wizards.

All orthogonal to C++'s design issues. IDEs typically bond with a compiler
and reuse its symbol table information. (Emacs supports this, too.) If you
can compile it, you can IDE it.

--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Jul 22 '05 #15

P: n/a
Alwyn wrote:
In article <Y5********************@speakeasy.net>, Steven T. Hatton
<su******@setidava.kushan.aa> wrote:

I believe you are right. It's a term used by the Extreme Programming
brigade. I'm not clear, however, how C# could provide better support
for them than any other language, since they are essentially user
acceptance tests, i.e. tests of the behaviour of the system from a
user's perspective.
It seem fairly understandable how C# could provide very good support for
such features. Since it can leverage introspection, and attributes, it can
examine your classes and produce the skeleton for your use cases much more
easily than the technique I am currently using. That is to write it all
out by hand in Emacs using the Boost Test Library's
boost::unit_test_framework::test_suite;
When studying computer science in college (while working fulltime) I was
inclined at one point to learn C++ as a focus.


Well, they taught me Pascal in my first year, and I had to write a
compiler in it. That's discipline for you!


My first programming courses were likewise in Pascal.
<snip>
This is a major reason IDE support is so weak in C++. IDE developers
have to deal with the poorly defined and unpredictable nature of C++
library management.
Real programmers distrust IDEs. I fear they have nurtured a generation
of technophobic 'softies' addicted to point-and-click and eye-candy.
Give me Emacs and proper command-line tools any day!

<snip>


You can't hide from progress forever:
http://cedet.sourceforge.net/
Here's a fun little one-liner for removing all the -gcc substrings from your
boost library names, and symlinking them to the original:

for f in libboost*.a libboost*.so;do ln -s $f ${f//-gcc/}; done

I have to admit, I like it when an IDE will completely generate the basic
framework of all the unit tests I need for a project, pull up the
documentation for any typename I select, automatically populate my headings
with the proper import statements, create the skeleton of the
implementation of an interface, automatically create interactive UML
diagrams for every class in my program linking them to eachother, and to
the source files they represent, present a list of available completions of
any fragment of code where it is meaningful, manage my development
application server, display the resulting web pages from running my applet,
painlessly integrate new libraries, provide the framework of the API
documentation, produce the html version of the API documentation from the
source code, show me the exact location of an error with the ability to
click on the error text and have the editor display the location of the
error, etc., etc. etc....
Yes, C++ is a more complex language, and it isn't as easy to
parse as the others, but that isn't the problem. That challenge cannot
be addressed because of the obstacles presented by the #include
mechanism.
Well yes, the C-based languages are missing proper module support. We
all know that, and it ain't gonna change any time soon.


Mostly because the the people who could facilitate the change lack the
vision to do so.
Anyway, over all, I thought your posting was a bit of a rant,
flamebait, even. It's just not good form to come to a C++ forum and
start lambasting the language from all directions. The people here have
chosen to learn C and C++ for various reasons, some good, some bad, no
doubt.


I think it's a crying shame so many C++ programmers refuse to acknowledge
there is significant room for improvement in the language.
--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.

Jul 22 '05 #16

P: n/a
Alwyn <dt********@mac.com.invalid> wrote in message news:<040920041426591920%dt********@mac.com.invali d>...
Real programmers distrust IDEs. I fear they have nurtured a generation
of technophobic 'softies' addicted to point-and-click and eye-candy.
Give me Emacs and proper command-line tools any day!


emacs like editors are great when the project is programming
intensive, you will have least distractions. But for projects which
use frameworks, IDEs create lots of boiler-palte code so that the
programmer can concentrate on creating application-specific code. IDEs
are not for the point-and-click programmers - there could be no
point-and-click programmers. Does typing again and again the same code
instead of letting some tool generate it for you make you any lesser
programmer? I don't understand the prejudice of some people against
the IDEs. Even emacs could be used as an IDE.

tabrez
Jul 22 '05 #17

P: n/a
Tabrez Iqbal wrote:
Alwyn <dt********@mac.com.invalid> wrote in message
news:<040920041426591920%dt********@mac.com.invali d>...
Real programmers distrust IDEs. I fear they have nurtured a generation
of technophobic 'softies' addicted to point-and-click and eye-candy.
Give me Emacs and proper command-line tools any day!


emacs like editors are great when the project is programming
intensive, you will have least distractions. But for projects which
use frameworks, IDEs create lots of boiler-palte code so that the
programmer can concentrate on creating application-specific code. IDEs
are not for the point-and-click programmers - there could be no
point-and-click programmers. Does typing again and again the same code
instead of letting some tool generate it for you make you any lesser
programmer? I don't understand the prejudice of some people against
the IDEs. Even emacs could be used as an IDE.

tabrez


When I find myself typing virtually identical code several times, I usually
realize soon that there is a template or a template/macro technique that
will unify the code. Are you sure that good C++ design has a significant
need for boilerplate code? I was under the impression that C++ provided
language features that allow you to put such code into a library and reuse
it via #include<blah.hh>. But then again, I do not know the specific
examples that you have in mind.
Best

Kai-Uwe Bux
Jul 22 '05 #18

P: n/a
Kai-Uwe Bux <jk********@gmx.net> wrote in message news:<ch**********@murdoch.acc.Virginia.EDU>...
When I find myself typing virtually identical code several times, I usually
realize soon that there is a template or a template/macro technique that
will unify the code. Are you sure that good C++ design has a significant
need for boilerplate code? I was under the impression that C++ provided
language features that allow you to put such code into a library and reuse
it via #include<blah.hh>. But then again, I do not know the specific
examples that you have in mind.
Best

Kai-Uwe Bux


With well designed libraries, or if application is created from
scratch, I quite agree with what you say. With some frameworks,
though, I feel it taxing to type the same code again and again -
consider MFC for example. I prefer designing GUI in visual mode and
let the IDE generate the code for it. Also the refactoring feature
provided by some IDEs is slowly becoming my favourite.

tabrez
Jul 22 '05 #19

P: n/a
Alwyn wrote:

In article <Y5********************@speakeasy.net>, Steven T. Hatton
<su******@setidava.kushan.aa> wrote:
Julie wrote:
Do you have the liberty to choose your language? If so, I'd recommend
looking at C# (and equivalent) were unit tests and story tests are much
better supported by the language.
Story test is not a term I am familiar with. Can you please explain what
this means? If forced to guess, I might speculate that these are basically
use cases?


I believe you are right. It's a term used by the Extreme Programming
brigade. I'm not clear, however, how C# could provide better support
for them than any other language, since they are essentially user
acceptance tests, i.e. tests of the behaviour of the system from a
user's perspective.


Better support because of some of the language extensions (reflection and
attributes) that allow the: underlying test framework to be much simpler; the
tests themselves to be defined quite simply.

These extensions are not *requirements*, but facilitate unit/story tests.
Real programmers distrust IDEs. I fear they have nurtured a generation
of technophobic 'softies' addicted to point-and-click and eye-candy.
Give me Emacs and proper command-line tools any day!


Well, then I guess I'm not a 'real' programmer. I guess you think that
magnetic storage media is too new-fangled as well, perhaps you still prefer
punch cards...?

Regardless, I'm happy to know that you have the authority to make sweeping
judgments about the validity of programmers.
Jul 22 '05 #20

This discussion thread is closed

Replies have been disabled for this discussion.