Hi!
I'm looking for unit-testing tools for .NET.
Somthing like Java has --> http://www.junit.org
regards,
gicio 14  2698 
HI Gicio,
Please take alook at NUnit - http://www.nunit.org/
Regards,
Aravind C
<gi***@web.de> wrote in message news:bo*************@news.hansenet.net... Hi!
I'm looking for unit-testing tools for .NET.
Somthing like Java has --> http://www.junit.org
regards,
gicio
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" <es****@attbi.com> wrote in message
news:uF**************@TK2MSFTNGP09.phx.gbl... 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" <se**************@6sens.com> wrote in message
news:uW**************@TK2MSFTNGP12.phx.gbl... 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]" <sk***@pobox.com> a écrit dans le message de news:
MP************************@msnews.microsoft.com... <gi***@web.de> wrote:
> 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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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]
- mv*@spam.guard.caspershouse.com
"Ben Rush" <kw*****@yahoo.com> wrote in message
news:Ot**************@TK2MSFTNGP10.phx.gbl... 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" <es****@attbi.com> wrote in message
news:uF**************@TK2MSFTNGP09.phx.gbl... 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" <se**************@6sens.com> wrote in message
news:uW**************@TK2MSFTNGP12.phx.gbl... 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]" <sk***@pobox.com> a écrit dans le message de
news: MP************************@msnews.microsoft.com...
> <gi***@web.de> wrote:
> > 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.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote: 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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote: 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.
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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" <as**@me.com> wrote in message
news:eT**************@TK2MSFTNGP10.phx.gbl... 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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote: 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.
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2****************@tk2msftngp13.phx.gbl... 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" <as**@me.com> wrote in message
news:eT**************@TK2MSFTNGP10.phx.gbl... 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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com>
wrote: > 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.
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Built verification testing is perfect for automation as is pre checkin
automated testing to prevent build breaks.
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:#6**************@tk2msftngp13.phx.gbl... 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" <as**@me.com> wrote in message
news:eT**************@TK2MSFTNGP10.phx.gbl... 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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com>
wrote: > 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.
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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" <st***********@mvps.org> wrote in message
news:ud**************@TK2MSFTNGP09.phx.gbl... I like csunit a little better for c#.
--
William Stacey, MVP
"SBC" <es****@attbi.com> wrote in message
news:uF**************@TK2MSFTNGP09.phx.gbl... 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" <se**************@6sens.com> wrote in message
news:uW**************@TK2MSFTNGP12.phx.gbl... 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]" <sk***@pobox.com> a écrit dans le message de
news: MP************************@msnews.microsoft.com...
> <gi***@web.de> wrote:
> > 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.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Tom Verbeure |
last post by:
Hello All,
so I'm now convinced that unit testing is really the way to go and I
want to add it to an existing project. The first thing that I find
out, is that, well, it's hard work. Harder than...
|
by: |
last post by:
Hi!
I'm looking for unit-testing tools for .NET.
Somthing like Java has --> http://www.junit.org
regards,
gicio
|
by: kferrara |
last post by:
I am looking for a unit testing tool to use with VB.net and ASP.net. Nunit
is good with VB.net however I haven't tried nUnitASP. Has anybody used any
other unit testing tools? Any suggestions...
|
by: |
last post by:
I am working on a web/webservice application that has a service layer. Most
service methods will perform an access-check before executing. This check
uses the IPrincipal credentials available in...
|
by: Enrique |
last post by:
Question
I am posting this question again (3rd time) because some issues with my no
spam alias.
Here it is the question:
I have not been able to run unit tests for a VSTO (2005) project. I...
|
by: Peter Rilling |
last post by:
Does VS.NET 2005 Professional support integrated unit testing, or is that
only with the team system?
|
by: Jacob |
last post by:
I have compiled a set og unit testing
recommendations based on my own experience
on the concept.
Feedback and suggestions for improvements
are appreciated:
...
|
by: Diffident |
last post by:
Hello All,
Can anyone please suggest me a good unit testing tool. I have seen NUnit but
not sure on how I can use it to test my methods which involve session
variables, viewstate variables,...
|
by: mo.sparrow |
last post by:
Typemock Isolator – A powerful mocking framework for .NET unit
testing and Test Driven Development (in Visual Studio).
http://www.typemock.com/learn_about_typemock_isolator.html
NUnit - A...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
