Develop Reference

Turning C# delegates into unit tests

In order to reduce code duplication I would like to generate unit tests programatically from various sources. One simple way I could think of was to generate a whole bunch of delegates from within a method that parses some configuration information and tags all those delegates with the [TestMethod] attribute which are then run by the visual studio test framework.
My motivation is to use as much of the visual studio's test reporting facilities as possible because I could write my own reporting layer for the tests by using some of C#'s reflection facilities but I rather not. My solution seems pretty elegant and simple but I can't get visual studio's test framework to understand what exactly I'm trying to do so does anyone know how to go about doing what I would like?

You may want to consider Pex (and possibly Moles for legacy code) from Microsoft Research. Pex is a research project that automatically generates unit tests with high code coverage, and supposedly picks interesting input and outputs for the tests. I guess there's some intelligence there. :)
I have not personally used it, but I have heard from some peers that Pex and Moles is pretty interesting and has helped them out. May be worth a look.
Hope this helps!

I think if you actually want to generate tests, you'd be best off literally generating the tests, using something like T4 templates. In other words, use code-generation and create the test fixtures and methods such that you run them as you would any other test case.

I'm sorry if this does not answer you question exactly but I think that auto-generating unit tests is the wrong way to tackle this problem.
Unit tests are an effective way to help avoid regression and provide documentation to how your code should be used. When you automatically generate your tests you get a bunch of tests but if they fail you don't really know if a real bug exist and you end up with a lot of failing tests that you have no idea why they fail or how to make them pass. At the end you would probably delete all of the tests - because they "don't work".
Having said that - try out Armadillo from Typemock - it's a tool that writes the tests according to the user's actions

Testing web applications

My question so general, but I think the answer will be specific.
All I want to know is:
Is there a way or steps or mechanism to test the application (web application) in a professional way?
Many times when I finish developing and try my application, testing it with dummy data several times, and when I think every thing is okay and I think I have covered all possible scenarios, I find I forgot important issues, or others tell me they found problems in my application.
How do I overcome this problem, and save my time?
Good links:
http://www.masukomi.org/talks/unit_testing_talk_2/index.xul?data=slide_data.txt#page215
http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
https://stackoverflow.com/questions/185021/rhino-mocks-good-tutorials
http://daptivate.com/archive/2008/02/12/top-10-best-practices-for-production-asp-net-applications.aspx
http://dotnetslackers.com/IIS/re-60499_What_is_It_is_an_error_to_use_a_section_registered_as_allowDefinition_MachineToApplication_beyond_application_level.aspx

As a proffesional tester my suggestion is that you should have a healthy mix of automated and manual testing.
AUTOMATED TESTING
Unit Testing
Use NUnit to test your classes, functions and interaction between them.
http://www.nunit.org/index.php
Automated Functional Testing
If it's possible you should automate a lot of the functional testing. Some frame works have functional testing built into them. Otherwise you have to use a tool for it. If you are developing web sites/applications you might want to look at Selenium.
http://www.peterkrantz.com/2005/selenium-for-aspnet/
Continuous Integration
Use CI to make sure all your automated tests run every time someone in your team makes a commit to the project.
http://martinfowler.com/articles/continuousIntegration.html
MANUAL TESTING
As much as I love automated testing it is, IMHO, not a substitute for manual testing. The main reason being that an automated can only do what it is told and only verify what it has been informed to view as pass/fail. A human can use it's intelligence to find faults and raise questions that appear while testing something else.
Exploratory Testing
ET is a very low cost and effective way to find defects in a project. It take advantage of the intelligence of a human being and a teaches the testers/developers more about the project than any other testing technique i know of. Doing an ET session aimed at every feature deployed in the test environment is not only an effective way to find problems fast, but also a good way to learn and fun!
http://www.satisfice.com/articles/et-article.pdf

Visual studio have a great test software
http://msdn.microsoft.com/en-us/library/ms182409.aspx
http://channel9.msdn.com/Blogs/briankel/Visual-Studio-Test-Professional-2010-The-Tool-for-the-Modern-Tester

Selenium is a great suite of tools to help test web applications. I'd recommend having a look at that.

This is a very big subject, there are hundreds of books written about software testing. The Wikipedia article should get you started on some concepts, but you really need to learn a lot more.
This SO question should be useful in choosing a book to start with.

I use http://xunit.codeplex.com in combination with http://www.jetbrains.com/resharper/.

Use either ms test framework or NUnit.
I recommend reading about unit tests and focused integration tests.
For full system tests use WatiN.

A lot more than a few nice tools goes into "professionally" testing any application.
But sticking with tools for the moment, a good tools for testing .Net sites is WatiN. And a good example of using WatiN in a real world situation is the DotNetNuke Automation Tests project. It is the continually growing set of automated tests that DotNetNuke Corp. is using to test DotNetNuke on a daily basis, and best of all it's open source.

References/guides for nunit unit testing

Can anyone sugggest good references/guides for getting started with nunit and visual studio 2008. (Apart from the Nunit documentation itself!). I specifically want to set up a test project in vs 2008.

There's a good book called "Pragmatic Unit Testing with NUnit" by Thompson and Hunt.
That's how I started and it provides a good introduction.
For more information on how and what to test in general I'd recomment "The Art of Unit Testing" by Osherove and "Test Driven Development" by Beck.
Also take a look at this helpful summary card also from Thompson and Hunt
http://media.pragprog.com/titles/utj/StandaloneSummary.pdf.
The concepts are further explained in their book.
Update:
Not sure I can recommend any books that describe the mechanics of setting up your project but I can offer some basic advice.
Create a separate test project for each source project you want to test.
Make sure you don't mix integration/system testing with your unit tests. One way to ensure this is to differentiate between test projects. e.g. I might have something like
CustomLibraryCode.proj //source project
CustomlibraryCodeTests.Unit.proj //unit test project
CustomLibraryCodeTests.Integration.proj //integration test project
This means that your unit tests which should be quick and easy to run can be executed in isolation from the integration tests, which typically might have dependencies on database, filesystem, etc., and tend to be slower and more brittle.

On top of other books mentioned, there is a new good book with loads of examples: Growing Object-Oriented Software, Guided by Tests

I just got The Art of Unit Testing with Examples in .NET by Roy Osherove. You can get it at Amazon and here is the site: http://artofunittesting.com/. It's pretty easy to understand. The book is written with examples in VS 2008 and Nunit. He also mentions other test frameworks.

Dimecasts has good, short screencasts covering NUnit
The page lists them in reverse order, so start at the bottom and work up!

NUnit vs. Visual Studio 2008's test projects for unit testing [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am going to be starting up a new project at work and want to get into unit testing. We will be using Visual Studio 2008, C#, and the ASP.NET MVC stuff. I am looking at using either NUnit or the built-in test projects that Visual Studio 2008 has, but I am open to researching other suggestions. Is one system better than the other or perhaps easier to use/understand than the other?
I am looking to get this project set up as kind of the "best practice" for our development efforts going forward.

Daok named all the pro's of Visual Studio 2008 test projects. Here are the pro's of NUnit.
NUnit has a mocking framework.
NUnit can be run outside of the
IDE. This can be useful if you want
to run tests on a non-Microsoft build server,
like CruiseControl.NET.
NUnit has more versions coming out
than visual studio. You don't have
to wait years for a new version.
And you don't have to install a new version of the IDE to
get new features.
There are extensions being developed
for NUnit, like row-tests, etc.
Visual Studio tests take a long time
to start up for some reason. This is
better in Visual Studio 2008,
but it is still too slow
for my taste. Quickly running a test
to see if you didn't break something
can take too long. NUnit with
something like Testdriven.Net to run
tests from the IDE is actually much
faster. Especially when running
single tests.
According to Kjetil Klaussen, this is caused by the Visual Studio testrunner. Running MSTest tests in TestDriven.Net makes MSTest performance comparable to NUnit.

The unit-testing framework doesn't actually matter much, because you can convert test classes with separate project files and conditional compilation (like this, Visual Studio → NUnit):
#if !NUNIT
using Microsoft.VisualStudio.TestTools.UnitTesting;
#else
using NUnit.Framework;
using TestClass = NUnit.Framework.TestFixtureAttribute;
using TestMethod = NUnit.Framework.TestAttribute;
using TestInitialize = NUnit.Framework.SetUpAttribute;
using TestCleanup = NUnit.Framework.TearDownAttribute;
using TestContext = System.String;
using DeploymentItem = NUnit.Framework.DescriptionAttribute;
#endif
The TestDriven.Net plugin is nice and not very expensive... With only plain Visual Studio 2008 you have to find the test from your test class or test list. With TestDriven.Net you can run your test directly from the class that you are testing. After all, unit tests should be easy to maintain and near the developer.

Benefits/changes of the Visual Studio 2008 built-in unit testing framework:
The 2008 version now is available in
professional editions (before it
required expensive versions of Visual Studio, and
this is just for developer unit
testing) that left a lot of
developers with the only choice of
open/external testing frameworks.
Built-in API supported by a single company.
Use the same tools to to run and create tests (you may run them using the command line also MSTest).
Simple design (granted without a mock framework, but this is a great starting point for many programmers).
Long term support granted (I still remember what happened to NDoc, and I don't want to commit to a testing framework that might not be supported in five years, but I still consider NUnit a great framework).
If using Team Foundation Server as your backend, you can create work items or bugs with the failed test data in a simple fashion.

I have been using NUnit for two years. All is fine, but I have to say that the unit testing system in Visual Studio is pretty nice, because it's inside the GUI and can more easily do a test for private function without having to mess around.
Also, the unit testing of Visual Studio lets you do covering and other stuff that NUnit alone can't do.

One slight annoyance of Visual Studio's testing framework is that it will create many test run files that tend to clutter your project directory - though this isn't that big of a deal.
Also, if you lack a plugin such as TestDriven.NET, you cannot debug your NUnit (or MbUnit, xUnit, etc.) unit tests within the Visual Studio environment, as you can with the Microsoft Visual Studio testing framework, which is built in.

Slightly off-topic, but if you go with NUnit I can recommend using ReSharper - it adds some buttons to the Visual Studio UI that make it a lot easier to run and debug tests from within the IDE.
This review is slightly out-of-date, but explains this in more detail:
Using ReSharper as an essential part of your TDD toolkit

xUnit is another possibility for a greenfield project. It's got perhaps a more intuitive syntax, but it is not really compatible with the other frameworks.

My main beef with Visual Studio unit tests over NUnit is the Visual Studio test creation tends to inject a bunch of generated code for private member access.
Some might want to test their private methods, and some may not. That's a different topic.
My concern is when I'm writing unit tests they should be extremely controlled so I know exactly what I'm testing and exactly how I'm testing it. If there's auto generated code I'm losing some of that ownership.

I have done some TDD using both and (maybe I'm a little dumb) NUnit seems to be a lot faster and simpler to use to me. And when I say a lot, I mean a lot.
In MSTest, there is too many attributes, everywhere - the code that do the real tests is the tiny lines you may read here and there. A big mess. In NUnit, the code that do the test just dominates the attributes, as it should do.
Also, in NUnit, you just have to click on the tests you want to run (only one? All the tests covering a class? An assembly? The solution?). One click. And the window is clear and large. You get clear green and red lights. You really know what happens in one sight.
In VSTS, the test list is jammed in the bottom of the screen, and it's small and ugly. You have to look twice to know what happened. And you cannot run just one test (well, I did not find out yet!).
But I may be wrong, of course - I just read about 21 blog posts about "How to do simple TDD using VSTS". I should have read more; you are right.
For NUnit, I read one. And I was TDDing the same day. With fun.
By the way, I usually love Microsoft products. Visual Studio is really the best tool a developer can buy - but TDD and Work Item management in Visual Studio Team System sucks, really.

First I want to correct a wrong statement: you can run MSTest outside of Visual Studio using the command line. Although several CI tools, such as TeamCity, have better support for NUnit (probably would change as MSTest becomes more popular).
In my current project we use both and the only big difference we found that MSTest always runs as a 32 bit while NUnit runs as either 32 bit or 64 bit tests which only matters if your code uses native code that is 32/64 bit dependent.

I got messages that "NUnit file structure is richer than VSTest"...
Of course, if you prefer the NUnit file structure, you can use this solution to the other way, like this (NUnit → Visual Studio):
#if !MSTEST
using NUnit.Framework;
#else
using Microsoft.VisualStudio.TestTools.UnitTesting;
using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
#endif
Or any other conversion... :-) This use here is just an alias to the compiler.

I started with MSTest, but I switched for one simple reason. MSTest does not support inheritance of test methods from other assemblies.
I hated the idea of writing the same test multiple times. Especially on a large project where test methods can easily run into 100's of tests.
NUnit does exactly what I need. The only thing that is missing with NUnit is a Visual Studio addin which has can display the red/green status (like VSTS) of each test.

If you are considering either MSTest or NUnit, then I recommend you look at MbUnit. My reasons are
TestDriven.Net compatibility. Nothing beats have TestDriven.Net.ReRunWithDebugger bound to a keyboard combination.
The Gallio framework. Gallio is a test runner like NUnit's. The only difference is it doesn't care if you wrote your tests in NUnit, MSTest, xUnit or MbUnit. They all get run.
Compatibility with NUnit. All features in NUnit are supported by MbUnit. I think you don't even need to change your attributes (will have to check that), just your reference and usings.
Collection asserts. MbUnit has more Assert cases, including the CollectionAssert class. Basically you no longer need to write your own tests to see if two collections are the same.
Combinatorial tests. Wouldn't it be cool if you could supply two sets of data and get a test for all the combinations of data? It is in MbUnit.
I originally picked up MbUnit because of its [RowTest ....] functionality, and I haven't found a single reason to go back. I moved all my active test suites over from NUnit and never looked back. Since then I've converted two different development teams over to the benefits.

As far as I know, there are four frameworks available for unit testing with .NET these days:
NUnit
MbUnit
MSTest
xUnit
NUnit has always been out in front, but the gap has closed in the last year or so. I still prefer NUnit myself, especially as they added a fluent interface a while back which makes tests very readable.
If you're just getting started with unit testing it probably doesn't make much difference. Once you're up to speed, you'll be in a better position to judge which framework is best for your needs.

I don't like the Visual Studio's built-in testing framework, because it forces you to create a separate project as opposed to having your tests as part of the project you're testing.

MSTest is essentially NUnit slightly reworked, with a few new features (such as assembly setup and teardown, not just fixture and test level), and missing some of the best bits (such as the new 2.4 constraint syntax). NUnit is more mature, and there is more support for it from other vendors; and of course since it's always been free (whereas MSTest only made it into the Professional version of Visual Studio 2008, and before that it was in way more expensive SKUs), and most ALT.NET projects use it.
Having said that, there are some companies who are incredibly reluctant to use something which does not have the Microsoft label on it, and especially so OSS code. So having an official Microsoft test framework may be the motivation that those companies need to get testing; and let's be honest, it's the testing that matters, not what tool you use (and using Tuomas Hietanen's code, you can almost make your test framework interchangeable).

With the release in .NET 4.0 of the Code Contracts system and the availability of a static checker, you would need to theoretically write fewer test cases and a tool like Pex will help identify those cases. Relating this to the discussion at hand, if you need to do less with your unit tests because your contracts are covering your tail, then why not just go ahead and use the built-in pieces since that is one less dependency to manage. These days, I am all about simplicity. :-)
See also:
Microsoft Pex – Automated Unit Testing
Unit Tests generation with Pex using Visual Studio 2010 and C# 4.0

I would prefer to use MS's little test framework, but for now am sticking with NUnit. The problems with MS's are generally (for me)
Shared "tests" file (pointless) that must be maintained
Tests lists cause conflicts with multiple developers / VCSs
Poor integrated UI - confusing setup, burdensome test selection
No good external runner
Caveats
If I were testing an aspx site, I would definitely use MS's
If I were developing solo, also MS would be fine
If I had limited skill and couldn't configure NUnit :)
I find it much easier to just write my tests and fire up NUnitGUI or one of the other front ends (testDriven is far far far far overpriced). Setting up debugging with the commandline version is also pretty easy.

What's the best way to implement BDD/TDD in .NET 2.0? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm looking to add a testing suite to my application, however I can't move to the newer testing frameworks for .NET 3.5.
Does anyone have a suggestion about good testing frameworks to use?

We use MbUnit and Rihno Mocks and they prove to work very well together. When doing TDD you will almost certainly need to do some form of dependency injection, while this can be done manually, its worth looking at an IoC container such as Castle Windsor.
It well worth looking at John Paul Bodhood's screen casts to get you started. JPB's Blog

NUnit and Rhino suit well and the auto-mocking container might be of interest.
If you're looking at BDD too then NBehave is probably a good choice. If however you just mean the style of BDD that relates to unit testing (xSpec) though you can get away with adding a framework (though things like specunit do add some synctactic sugar), but you might want to look at MSpec is also interesting.

Check out Rob Conery's screencast on BDD using MSpec. Very impressive http://blog.wekeroad.com/mvc-storefront/kona-3/
edit: I now use this approach: http://10printhello.com/the-one-bdd-framework-to-rule-them/

For a Mock Object library, I've found the BSD-licensed Rhino.Mocks to be rather pleasing.

I've had great success using NUnit as well.
I've also used NMock when the need arose for mock objects. As an added bonus, the factory for creating your mock objects is called the Mockery.
To facilitate the running of unit tests, I've used TestDriven.NET to run unit tests as I coded. Also, I've used Cruise Control .NET to watch SVN and check that every new commit builds and passes all unit tests.

This is probably a summary of what has already been said, but for TDD I personally use Rhino Mocks and MBUnit. Rhino Mocks is a mocking framework that is free and open source. The advantage of Rhino Mocks is we do not need to use magic strings in setting your expectations as you do in NMock.
I like MBUnit because MbUnit has the concept of RowTests which allow you to vary your inputs to your test method. MBUnit is also freely available.
You also want to make sure that whatever you choose for your unit testing framework is supported by your CI (Continuous Integration Server). Nunit is supported by default in Cruise Control.NET and you have to do a little extra work to get MBUnit to work in ccnet.
From an IDE standpoint you must have TestDriven.NET. TestDriven.NET allows you to right click and run tests in the IDE and it supports MBUnit and Nunit and others.
NBehave is the BDD library I have used. I have not used any others so I could not compare and contrast them with you, but NBehave is supported by Gallio from the MBUnit team, which means you can run your BDD tests just as you would your unit tests with TestDriven.NET.
I would also highly recommend Resharper. You will find your productivity increase significantly with this refactoring and guidance tool. It will assist you with changing your code as you are developing your tests.
Hope this helps

Using nUnit with TFS isn't too difficult. There's even a project on codeplex to implement this: NUnit for Team Build which even "publishes" the results to the warehouse.
I haven't tried it - but I would advise clients who have a large investment (or who have a strong preference for it over the MSTest tool) in nUnit who are interested in implementing TFS to continue with nUnit as opposed to trying convert all their existing tests.

NUnit is available at http://www.nunit.org
I would suggest this even when working on the MS stack - the support for non-MS frameworks is happening in the MVC previews which shows a definite movement in the right direction to allow us all to customise our stacks to fit.

I have to put a shout-out for Moq. It is a clean light mocking framework that guides you into the pit of success.
The testing tools built into TFS are okay. They will get the job done but can often be a little cumbersome to work with. The generated reports, code coverage and a few other portions are particularly bad. They make you go bald at 22 rather than 50.
If you are really loving the testing, consider trying some Continuous Integration. You will feel the pain from regression quickly and this pain potentially helps you get to the end goal faster.
Regardless of what you do, try out a few and see which one is the most natural, if you have time. Good luck and happy coding.

NUnit is always a favorite of mine. However if you are using TFS as your source control I suggest you stick with the Microsoft Stack.

I recommend the following:
TestDriven.NET - Unit Testing add on for VS that is fully integrated with all major unit testing frameworks including NUnit, MbUnit etc...
Typemock Isolator- A mocking framework for .Net Unit Testing
NUnit - An open source unit testing framework that is in C#.

For my project, I used NUnit and TestDriven.NET with great success. You can either create a separate library just to host your test code or put it in your executable or library. It all depends on whether you want your production code to be intertwined with your test code.
For Dependency Injection, I use NInject in my current project and it works great. If you use Constructor injection, you don't need to clutter your code with the [Inject] attribute.
I haven't used a mock library for my .NET 2.0 project but for another .NET 3.5 project I will use Moq.
Note that all these work with .NET 2.0 and higher. (except Moq)