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

Unit Testing

P: n/a
Hi,

In an effort to improve my own code and try to teach others that I work with
that unit testing IS MANDATORY. I'm interested in examples of unit testing
that other people are using.

How many folks rely on NUNIT?

Do you create a testing class per application, per class, per assembly to
exercise your code?

Do you know of any links that show examples of how the "Agile process"
incorporates unit testing into its process?

Know of any code in source forge that contains testing code?

How have to standardized your testing classes/code so that it "looks" and
"feels" the same and isn't totally confusing to outsiders that may have to
maintain your code?

Do you embed your test class into the same assembly as the class it tests?
I like this idea because it keeps someone else from breaking your code (at
least making sure it compiles) when they come in to do a "quick" change.

I would appreciate any links or book recommendations on the subject.

Thanks,
Dave
Dec 9 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
D. Yates <fo****@hotmail.com> wrote:
In an effort to improve my own code and try to teach others that I work with
that unit testing IS MANDATORY. I'm interested in examples of unit testing
that other people are using.

How many folks rely on NUNIT?
<raises hand>
Do you create a testing class per application, per class, per assembly to
exercise your code?
Per class, usually.
Do you know of any links that show examples of how the "Agile process"
incorporates unit testing into its process?
I suspect pretty much any description of Agile coding is likely to
mention unit testing. I don't have any specific links off-hand though.
Know of any code in source forge that contains testing code?
Pretty much any test tool project will have test code. Other examples
are Spring and Hibernate - both Java projects, but I'd expect their
..NET equivalents to have test clode too.
How have to standardized your testing classes/code so that it "looks" and
"feels" the same and isn't totally confusing to outsiders that may have to
maintain your code?
We tend to use m_subject as a member variable which refers to an
instance of the class under test, for starters.
Do you embed your test class into the same assembly as the class it tests?
I like this idea because it keeps someone else from breaking your code (at
least making sure it compiles) when they come in to do a "quick" change.


No, we use a different project in the same solution. You don't really
want test code bloating the release DLL - especially if you embed test
data files. On the other hand, if you don't mind a little bit of extra
space and don't mind the possibility of people finding your tests, it's
a great way to allow easy testing of internal members too.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 9 '05 #2

P: n/a
I would agree with Jon, we take a similar approach.

Use NUnit, test per class and keep our test classes seperate from the
main application.

Dec 9 '05 #3

P: n/a
VS2005TS has sample code on the we fly 247 demo CD

Dec 9 '05 #4

P: n/a
D. Yates wrote:

I would appreciate any links or book recommendations on the subject.


Here are a couple of links which you might find useful:

http://groups.yahoo.com/group/TestDrivenDevelopment/

http://www.testdriven.com
Angus Miller

Dec 9 '05 #5

P: n/a
Jon,

Thanks for your response.

How do you handle application testing provided that your unit testing
passes? Do you just use human testers or is your testing automated in
anyway?

Dave
Dec 9 '05 #6

P: n/a
Angus,

Thanks for your response.

I noticed that on the test driven site they reference a book called
"Test-Driven Development in .NET". Do you own this book? If so, what are
your thoughts as to its worth. In other words, do you refer to it often or
almost never.....

Thanks,
Dave

"A Miller" <an***@amlsoftwarexx.co.uk> wrote in message
news:ek*************@TK2MSFTNGP12.phx.gbl...
D. Yates wrote:

I would appreciate any links or book recommendations on the subject.


Here are a couple of links which you might find useful:

http://groups.yahoo.com/group/TestDrivenDevelopment/

http://www.testdriven.com
Angus Miller


Dec 9 '05 #7

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote:

[...]
Do you embed your test class into the same assembly as the class it tests?
I like this idea because it keeps someone else from breaking your code (at
least making sure it compiles) when they come in to do a "quick" change.


No, we use a different project in the same solution. You don't really
want test code bloating the release DLL - especially if you embed test
data files. On the other hand, if you don't mind a little bit of extra
space and don't mind the possibility of people finding your tests, it's
a great way to allow easy testing of internal members too.


Still, you can use conditional compilation to exclude test code from
release builds.
Dec 9 '05 #8

P: n/a
I noticed that on the test driven site they reference a book called
"Test-Driven Development in .NET". Do you own this book? If so,
what are your thoughts as to its worth. In other words, do you refer
to it often or almost never.....

That's not a book I know. One I can recommend is 'Working Effectively
with Legacy Code' by Michael Feathers - which gives lots of examples of
how you can implement TDD with your currently untested code.

http://www.amazon.com/gp/product/013.../sr=1-1/ref=sr
_1_1/102-3508174-2971300?s=books&v=glance&n=283155
Angus Miller
Dec 9 '05 #9

P: n/a
D. Yates <fo****@hotmail.com> wrote:
Thanks for your response.

How do you handle application testing provided that your unit testing
passes? Do you just use human testers or is your testing automated in
anyway?


We have some automated tests and some manual tests. Obviously, some
types of UI are easier to test than others - and many integration level
tests can be done at the web service level rather than at the visible
UI level.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 9 '05 #10

P: n/a
Cool Guy <co*****@abc.xyz> wrote:
No, we use a different project in the same solution. You don't really
want test code bloating the release DLL - especially if you embed test
data files. On the other hand, if you don't mind a little bit of extra
space and don't mind the possibility of people finding your tests, it's
a great way to allow easy testing of internal members too.


Still, you can use conditional compilation to exclude test code from
release builds.


Yes, but then you're not testing what you're releasing. There's a
definite appeal to running unit tests on the *real* code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 9 '05 #11

P: n/a
A Miller <an***@amlsoftwarexx.co.uk> wrote:
I noticed that on the test driven site they reference a book called
"Test-Driven Development in .NET". Do you own this book? If so,
what are your thoughts as to its worth. In other words, do you refer
to it often or almost never.....


That's not a book I know. One I can recommend is 'Working Effectively
with Legacy Code' by Michael Feathers - which gives lots of examples of
how you can implement TDD with your currently untested code.

http://www.amazon.com/gp/product/013.../sr=1-1/ref=sr
_1_1/102-3508174-2971300?s=books&v=glance&n=283155


While I haven't read that one myself, I believe it's the one my team
leader absolutely swears by. It's sort of "testing in the real world,
where things get icky."

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 9 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.