Unit testing tools for .NET ?

  • Thread starter Thread starter Guest
  • Start date Start date
I would be interested in hearing some real-world success stories using Unit
testing. Our company employed it and I have to honestly say that it really
didn't help much. I would completely accept the fact that we did it
incorrect, or used it improperly since this was our first time using it, but
it just didn't save us from that many bugs.

Do people typically have the developers who write the code write the unit
tests? Do you people typically have their QA department write the tests?

The most practical use we found for unit testing was for "after-the-fact"
testing. In other words, we identified what area caused a bug, and then
wrote a unit test to make sure that it was fixed. That way we can regression
test easier in the future. But, I'm interested in other people's thoughts
and experiences on this topic. I hear a lot of people point towards NUnit,
but I never hear how it was used in the field.

We do web applications, so we used NunitASP as well, but used classic NUnit
for our libraries.

Thanks,
Ben


SBC said:
There's also csUnit (http://www.csunit.org/index.php).
There's also a weblog posting about unit testing tools:
http://weblogs.asp.net/sbchatterjee/posts/29566.aspx

SBC
Click to expand...
 
Ben,

I think that having the developers write the testing code is not a good
idea at all. Granted, they might actually have to ^write^ the code, but the
user cases should be created by QA or whomever helps decide what the
functionality should be and how the user will do it. It is a collaborative
process, because some people can think of things that others can not, but
generally, the people using the software (or the people who understand how
it is going to be used) should create the tests.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Ben Rush said:
I would be interested in hearing some real-world success stories using Unit
testing. Our company employed it and I have to honestly say that it really
didn't help much. I would completely accept the fact that we did it
incorrect, or used it improperly since this was our first time using it, but
it just didn't save us from that many bugs.

Do people typically have the developers who write the code write the unit
tests? Do you people typically have their QA department write the tests?

The most practical use we found for unit testing was for "after-the-fact"
testing. In other words, we identified what area caused a bug, and then
wrote a unit test to make sure that it was fixed. That way we can regression
test easier in the future. But, I'm interested in other people's thoughts
and experiences on this topic. I hear a lot of people point towards NUnit,
but I never hear how it was used in the field.

We do web applications, so we used NunitASP as well, but used classic NUnit
for our libraries.

Thanks,
Ben


SBC said:
There's also csUnit (http://www.csunit.org/index.php).
There's also a weblog posting about unit testing tools:
http://weblogs.asp.net/sbchatterjee/posts/29566.aspx

SBC


Sebastien Lambla said:
I may add the excellent NUnit Addin for integration with visual studio.net

http://weblogs.asp.net/NUnitAddin/

You can also look at mock objects, which are a different approach of unit
testing...

--
Sebastien Lambla
http://thetechnologist.is-a-geek.com/blog/


"Jon Skeet [C# MVP]" <[email protected]> a écrit dans le message de (e-mail address removed)...
I'm looking for unit-testing tools for .NET.
Somthing like Java has --> http://www.junit.org

See http://nunit.sf.net - and please limit your cross-posting in
future.
Click to expand...
Click to expand...
Click to expand...
 
Nicholas Paldino said:
I think that having the developers write the testing code is not a good
idea at all. Granted, they might actually have to ^write^ the code, but the
user cases should be created by QA or whomever helps decide what the
functionality should be and how the user will do it. It is a collaborative
process, because some people can think of things that others can not, but
generally, the people using the software (or the people who understand how
it is going to be used) should create the tests.
Click to expand...

Most unit tests I've written haven't had anything to do with the user
experience - that should usually be more covered by system tests (or at
least, it's considerably harder to unit test than business logic etc).

IMO, unit tests should (if possible) be written before the code that
they're testing is written. It shouldn't be about user input, it should
be about as wacky and wild input as possible to the methods, as well as
more normal input, of course.

I don't unit test as often as I probably should, I'm afraid to say, but
when I do it often has signficant results. Sometimes the unit test code
ends up being longer than the code it's testing, but it usually finds
problems which otherwise might not have been found.
 
I agree with Jon - the test should be written first, and absolutely must be
written by the same programmer as is writing the code. There seems to be
some confusion over what "unit tests" really are. As far as I've seen, unit
tests are small pieces of code written by a programmer to specifically
target pieces of required functionality, and ensure that the functionality
behaves properly. They're not usually high level tests, they are almost
always very small and specific.

Tests like someone saying "When I click this button, I want the form to save
and bring up the next one" is what I have heard called a User Acceptance
Test. A unit test would be more like code that calls a square root function
with 4 and makes sure it gets 2 back, then calls it with a few other
numbers, and calls it with -1 and makes sure it gets an exception, etc.

So with this definition of unit testing in mind, I think it's best that the
programmer who will be writing the business logic writes the test, and that
they do it first. They write the test to specify exactly what behaviour is
expected of the small piece of functionality they are about to write. Then
they write the functionality and use the test to tell if they have done it
properly. ANy time new functionality is needed or a bug is found, it should
be expressed as a test first, then implemented. This way, you end up with a
large collection of very small tests, such that when one fails, you get a
very strong indication of what has gone wrong, and hence you know where to
look.

User Acceptance Testing should definitely use tests written by people other
than the original programmer...

Niall
 
Here is my two pence on this. I've missed the unit testing boat completely.
Using the debugger is so hard grained into me that it is extremely painful
to do otherwise. Maybe they should start unit tests in school, that way it
is part of the process. It would help if a department enforces this as part
of its programming requirements, but here, I practically am the dept so
enforcement sleeps late most mornings.

I'm all for it though, I see it's benefit in eliminating certain types of
bugs but bad habits run so deep. In the end, if you do things a certain way,
you always will unless you are motivated to do otherwise. The motivation is
less for me because what I am doing works reasonably well.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
Niall said:
I agree with Jon - the test should be written first, and absolutely must be
written by the same programmer as is writing the code. There seems to be
some confusion over what "unit tests" really are. As far as I've seen, unit
tests are small pieces of code written by a programmer to specifically
target pieces of required functionality, and ensure that the functionality
behaves properly. They're not usually high level tests, they are almost
always very small and specific.

Tests like someone saying "When I click this button, I want the form to save
and bring up the next one" is what I have heard called a User Acceptance
Test. A unit test would be more like code that calls a square root function
with 4 and makes sure it gets 2 back, then calls it with a few other
numbers, and calls it with -1 and makes sure it gets an exception, etc.

So with this definition of unit testing in mind, I think it's best that the
programmer who will be writing the business logic writes the test, and that
they do it first. They write the test to specify exactly what behaviour is
expected of the small piece of functionality they are about to write. Then
they write the functionality and use the test to tell if they have done it
properly. ANy time new functionality is needed or a bug is found, it should
be expressed as a test first, then implemented. This way, you end up with a
large collection of very small tests, such that when one fails, you get a
very strong indication of what has gone wrong, and hence you know where to
look.

User Acceptance Testing should definitely use tests written by people other
than the original programmer...

Niall

but
Click to expand...
 
Well, the whole idea of test first is very foreign to programmers. Usually
programmers think of the problem, think about how they could implement it,
scratch out the framework of the solution, think a bit more about how to
make it fit the problem, and go.

At least this is the way I (used to) work. It seemed odd to me to write a
test before I wrote the code, because I didn't actually know exactly what I
was doing until I had started putting up the structure and had seen whether
my idea would fit or not. By making yourself test first, you're really
forcing your mind to split up thinking on "what you need to do" and "how
you'll do it". I find that this often results in both a more full
examination of requirements, as well as a better implementation. I guess
maybe things are different for me, as I'm in a reasonably large team where
unit testing is expected of us, so there is more pressure to pick up unit
testing, though certainly some have embraced it more than others.

Niall

Alvin Bruney said:
Here is my two pence on this. I've missed the unit testing boat completely.
Using the debugger is so hard grained into me that it is extremely painful
to do otherwise. Maybe they should start unit tests in school, that way it
is part of the process. It would help if a department enforces this as part
of its programming requirements, but here, I practically am the dept so
enforcement sleeps late most mornings.

I'm all for it though, I see it's benefit in eliminating certain types of
bugs but bad habits run so deep. In the end, if you do things a certain way,
you always will unless you are motivated to do otherwise. The motivation is
less for me because what I am doing works reasonably well.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
Niall said:
I agree with Jon - the test should be written first, and absolutely must be
written by the same programmer as is writing the code. There seems to be
some confusion over what "unit tests" really are. As far as I've seen, unit
tests are small pieces of code written by a programmer to specifically
target pieces of required functionality, and ensure that the functionality
behaves properly. They're not usually high level tests, they are almost
always very small and specific.

Tests like someone saying "When I click this button, I want the form to save
and bring up the next one" is what I have heard called a User Acceptance
Test. A unit test would be more like code that calls a square root function
with 4 and makes sure it gets 2 back, then calls it with a few other
numbers, and calls it with -1 and makes sure it gets an exception, etc.

So with this definition of unit testing in mind, I think it's best that the
programmer who will be writing the business logic writes the test, and that
they do it first. They write the test to specify exactly what behaviour is
expected of the small piece of functionality they are about to write. Then
they write the functionality and use the test to tell if they have done it
properly. ANy time new functionality is needed or a bug is found, it should
be expressed as a test first, then implemented. This way, you end up
Click to expand...
with
Click to expand...
 
Built verification testing is perfect for automation as is pre checkin
automated testing to prevent build breaks.



Alvin Bruney said:
Here is my two pence on this. I've missed the unit testing boat completely.
Using the debugger is so hard grained into me that it is extremely painful
to do otherwise. Maybe they should start unit tests in school, that way it
is part of the process. It would help if a department enforces this as part
of its programming requirements, but here, I practically am the dept so
enforcement sleeps late most mornings.

I'm all for it though, I see it's benefit in eliminating certain types of
bugs but bad habits run so deep. In the end, if you do things a certain way,
you always will unless you are motivated to do otherwise. The motivation is
less for me because what I am doing works reasonably well.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
Niall said:
I agree with Jon - the test should be written first, and absolutely must be
written by the same programmer as is writing the code. There seems to be
some confusion over what "unit tests" really are. As far as I've seen, unit
tests are small pieces of code written by a programmer to specifically
target pieces of required functionality, and ensure that the functionality
behaves properly. They're not usually high level tests, they are almost
always very small and specific.

Tests like someone saying "When I click this button, I want the form to save
and bring up the next one" is what I have heard called a User Acceptance
Test. A unit test would be more like code that calls a square root function
with 4 and makes sure it gets 2 back, then calls it with a few other
numbers, and calls it with -1 and makes sure it gets an exception, etc.

So with this definition of unit testing in mind, I think it's best that the
programmer who will be writing the business logic writes the test, and that
they do it first. They write the test to specify exactly what behaviour is
expected of the small piece of functionality they are about to write. Then
they write the functionality and use the test to tell if they have done it
properly. ANy time new functionality is needed or a bug is found, it should
be expressed as a test first, then implemented. This way, you end up
Click to expand...
with
Click to expand...
 
Why do you prefer csunit?


William Stacey said:
I like csunit a little better for c#.

--
William Stacey, MVP

SBC said:
There's also csUnit (http://www.csunit.org/index.php).
There's also a weblog posting about unit testing tools:
http://weblogs.asp.net/sbchatterjee/posts/29566.aspx

SBC


Sebastien Lambla said:
I may add the excellent NUnit Addin for integration with visual studio.net

http://weblogs.asp.net/NUnitAddin/

You can also look at mock objects, which are a different approach of unit
testing...

--
Sebastien Lambla
http://thetechnologist.is-a-geek.com/blog/


"Jon Skeet [C# MVP]" <[email protected]> a écrit dans le message de (e-mail address removed)...
I'm looking for unit-testing tools for .NET.
Somthing like Java has --> http://www.junit.org

See http://nunit.sf.net - and please limit your cross-posting in
future.
Click to expand...
Click to expand...
Click to expand...
 
Don't forget that csUnit has been released under the GPL (NUnit is not)
which can have an impact on what you can do with it if you produce
commercial systems (if you want to ship your test libraries or include the
tests directly in your production assembly for example).

--
----------------------------------------------------------------
Peter Provost
Weblog: http://www.peterprovost.org/
----------------------------------------------------------------



William Stacey said:
I like csunit a little better for c#.

--
William Stacey, MVP

SBC said:
There's also csUnit (http://www.csunit.org/index.php).
There's also a weblog posting about unit testing tools:
http://weblogs.asp.net/sbchatterjee/posts/29566.aspx

SBC


Sebastien Lambla said:
I may add the excellent NUnit Addin for integration with visual studio.net

http://weblogs.asp.net/NUnitAddin/

You can also look at mock objects, which are a different approach of unit
testing...

--
Sebastien Lambla
http://thetechnologist.is-a-geek.com/blog/


"Jon Skeet [C# MVP]" <[email protected]> a écrit dans le message de (e-mail address removed)...
I'm looking for unit-testing tools for .NET.
Somthing like Java has --> http://www.junit.org

See http://nunit.sf.net - and please limit your cross-posting in
future.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top