The Art of Unit Testing

Roy Osherove

Mentioned 50

A guide to the concept of unit testing provides step-by-step instructions and covers such topics as test patterns and organization, legacy code, mock objects, and automated frameworks.

More on

Mentioned in questions and answers.

What book would you recommend to learn test driven development? Preferrably language agnostic.

Growing Object-Oriented Software, Guided by Tests by Addison-Wesley - it is about mocking frameworks - JMock and Hamcrest in particular.

From description of the book:

Steve Freeman and Nat Pryce describe the processes they use, the design principles they strive to achieve, and some of the tools that help them get the job done. Through an extended worked example, you’ll learn how TDD works at multiple levels, using tests to drive the features and the object-oriented structure of the code, and using Mock Objects to discover and then describe relationships between objects. Along the way, the book systematically addresses challenges that development teams encounter with TDD--from integrating TDD into your processes to testing your most difficult features.

EDIT: I'm now reading Working Effectively with Legacy Code by Michael Feathers which is pretty good. From the description of the book:

  • Understanding the mechanics of software change: adding features,
    fixing bugs, improving design, optimizing performance
  • Getting legacy code into a test harness
  • Writing tests that protect you against introducing new problems
  • This book also includes a catalog of twenty-four dependency-breaking techniques that help you work with program elements in isolation and make safer changes.

I read it already, it is one of the best programming books I've ever read (I personally think that it must be called Refactoring to Testability - it describes the processes for making your code testable). Because a testable code is good code.

The Astels book is a solid introduction, Beck's book is good on the underlying concepts, Lasse Koskela has a newish one (Test Driven: TDD and Acceptance TDD for Java Developers). Osherove's book, as he says, is about Unit Testing, rather than TDD. I'm not sure that the Pragmatics' TDD book has aged as well as their original book.

Most everything is Java or C#, but you should be able to figure it out yourself.

For me, this is the best one:

I am looking for podcasts or videos on how to do unit testing.

Ideally they should cover both the basics and more advanced topics.

Other hanselminutes episodes on testing:

Other podcasts:

Other questions like this:

Blog posts:

I know you didn't ask for books but... Can I also mention that Beck's TDD book is a must read, even though it may seem like a dated beginner book on first flick through (and Working Effectively with Legacy Code by Michael C. Feathers of course is the bible). Also, I'd append Martin(& Martin)'s Agile Principles, Patterns & Techniques as really helping in this regard. In this space (concise/distilled info on testing) also is the excellent Foundations of programming ebook. Goob books on testing I've read are The Art of Unit Testing and xUnit Test Patterns. The latter is an important antidote to the first as it is much more measured than Roy's book is very opinionated and offers a lot of unqualified 'facts' without properly going through the various options. Definitely recommend reading both books though. AOUT is very readable and gets you thinking, though it chooses specific [debatable] technologies; xUTP is in depth and neutral and really helps solidify your understanding. I read Pragmatic Unit Testing in C# with NUnit afterwards. It's good and balanced though slightly dated (it mentions RhinoMocks as a sidebar and doesnt mention Moq) - even if nothing is actually incorrect. An updated version of it would be a hands-down recommendation.

More recently I've re-read the Feathers book, which is timeless to a degree and covers important ground. However it's a more 'how, for 50 different wheres' in nature. It's definitely a must read though.

Most recently, I'm reading the excellent Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. I can't recommend it highly enough - it really ties everything together from big to small in terms of where TDD fits, and various levels of testing within a software architecture. While I'm throwing the kitchen sink in, Evans's DDD book is important too in terms of seeing the value of building things incrementally with maniacal refactoring in order to end up in a better place.

I do write unit tests while writing APIs and core functionalities. But I want to be the cool fanboy who eats, sleeps and breathes TDD and BDD. What's the best way to get started with TDD/BDD the right way? Any books, resources, frameworks, best practices?

My environment is Java backend with Grails frontend, integrated with several external web services and databases.

A good place to start is reading blogs. Then buy the books of the people who are blogging. Some I would highly recommend:

"Uncle Bob" Martin and the guys at Object Mentor:

P.S. get Bobs book Clean Code:

My friend Tim Ottinger (former Object Mentor dude)

The Jetbrains guys:

I felt the need to expand on this, as everyone else seems to just want to give you their opinion of TDD and not help you on your quest to become a Jedi-Ninja. The Michael Jordan of TDD is Kent Beck. He really did write the book on it:

he also blogs at:

other "famous" supporters of TDD include:

All are great people to follow. You should also consider attending some conferences like Agile 2010, or Software Craftsmanship (this year they were held at the same time in Chicago)

I've been doing TDD for a couple of years, but lately I've started looking more in to the BDD way of driving my design and development. Resources that helped me get started on BDD was first and formost Dan North's blog (the 'founder' of BDD). Take a look at Introducing BDD. There's also an 'official' BDD Wiki over at with some good post well worth reading.

The one thing that I found really hard when starting out with BDD (and still find a bit hard) is how to formulate those scenarios to make them suitable to BDD. Scott Bellware is a man well skilled in BDD (or Context-Spesification as he like to coin it) and his article Behavior-Driven Development in Code Magazine helped me a lot on understanding the BDD way of thinking and formulating user stories.

I would also recomend the TekPub screencast Behavior-driven Design with Specflow by Rob Conery. A great intro to BDD and to a tool (SpecFlow) very good suited for doing BDD in C#.

As for TDD resources, there's already a lot of good recommendations here. But I just want to point out a couple of books that I can really recommend;

I am a C# winforms developer with an experience of around a year. The only unit testing that I have been doing till now has been manual. I have thinking about following for sometime:

  • Why do we need to have automated unit testing? How effective is it?
  • If I want to start doing automated unit testing. Where should I start from? (have heard about nunit)
  • Do I need to keep anything in mind when designing my classes to facilitate automated unit testing?
  • Does C# have an in-built support for automated unit testing?
  • Can we also test GUI with automated unit testing or is it just business logic?
  • Have heard about mocking frameworks. Are they also for unit testing?

Why do we need to have automated unit testing? How effective is it?

Automated unit testing is very valuable first and foremost because it is automatable (normally, we only consider it a 'unit test' when it is automatable). As the size of an application grows, manually testing the whole application may take hours or even weeks. Even testing just a small part of an application takes time and is error-prone. Unless you are autistic, you will not be able to focus on performing each manual test 100% correctly if you have to do it over and over dozens of times.

In Agile development, we operate with the concept of Rapid Feedback: the sooner you can get feedback about what you did was right or wrong, the more effective you can be. We all make mistakes, but it is a lot less expensive to discover and fix a mistake thirty seconds after it was made, than several days or weeks later. That is why automated testing is so important.

While you can do automated testing on many levels, unit testing is the most efficient type to implement. It may be the most difficult testing discipline to understand and master, but it is much more robust than any other type of testing.

If I want to start doing automated unit testing. Where should I start from? (have heard about nunit)

First of all, you need to learn some unit testing basics. Roy Osherove's book The Art of Unit Testing is a good introduction.

When it comes to frameworks, NUnit has been around for a long time, but it has some inherent issues.

If you already have Visual Studio Professional or Team System, there's a built-in unit testing framework commonly known as MSTest. Most people dislike this framework, but personally, I find it quite adequate. The IDE integration works well, but the API could be better.

If you are looking for a free, open source unit testing framework, I would recommend, which is a much more modern framework.

Do I need to keep anything in mind when designing my classes to facilitate automated unit testing?

Yes, each class should be able to be used in isolation. This can be very hard to do by up-front design, or if you are trying to retrofit unit tests onto existing code, but should come more or less naturally if you adopt Test-Driven Development (TDD).

Does C# have an in-built support for automated unit testing?

No, C# is just a language, but as I mentioned above, certain versions of Visual Studio has MSTest.

Can we also test GUI with automated unit testing or is it just business logic?

Unit testing GUI tends to be very brittle (that is, test maintainance is very high), so is generally not a good idea.

However, there are many design patterns that can help you extract all GUI logic into testable classes: Modev-View-Controller, Model-View-Presenter, Application Controller, Model-View-ViewModel, etc.

You can perform automated tests of an entire application via such interfaces, bypassing only the GUI rendering part. Such tests are called Subcutaneous Tests, but are considered Integration Tests, not unit tests.

Have heard about mocking frameworks. Are they also for unit testing?

Dynamic mock libraries are only for unit testing.

Some good and popular ones are

Where can I find good literature on unit testing? Book titles and links are welcome.

Update: Here is a list of books mentioned in answers below

xUnit Test Patterns: Refactoring Test Code

Growing Object-Oriented Software Guided by Tests

The Art Of Unit Testing

The real challenge of software testing is solving the puzzle of test design.

Testing Object-Oriented Systems: Models, Patterns, and Tools provides three dozen test design patterns applicable to unit test design. It also provides many design patterns for test automation. These patterns distill many hard-won best practices and research insights.

Pragmatic Unit Testing

Test Driven Development: By Example

I have some 5+ years' background in C++/Unix development. I have been trying my hand at C#/.Net/WPF based software development for some time now. I am at a stage where I can write functioning applications fluently, but am not sure how to take my skills to the next level.

So, my question(s) to you all, especially to those who are experienced in C#/.Net/WPF:

  • What are the component skills and knowledge that an expert developer on this platform should have?

  • What technology-specific books would you expect a would-be expert to have read?

  • What other deliberate steps can I take to become really good at application development using C#/.Net/WPF?

Many thanks in advance! I would be especially grateful for comprehensive answers - I'm pretty sure many other developers have similar questions.

Learn how the C# language and .NET runtime work by reading CLR via C#.

I really like WPF in Action and Programming .NET Components is essential reading for any .NET developer.

My team has worked in C# for the past 5 years. Typically, experienced C++ programmers take a week or two to become fully functional in C#. I've even seen some do it almost instantly, after sitting with them one morning, showing them our code, and explaning the basics of the language that differ from C++. But that's not how I recommend you do it.

I recommend you do this:

Read a C# book: My pick would be Programming C# by Jesse Liberty. Important chapters are the language itself and the basics of the .NET framework libraries. The .NET Framework is huge, so you don't have to know everything in detail. You can skip through (or skim) the Windows Forms chapters. Windows Forms is so different from WPF that it won't be useful to you if you are planning on only doing WPF.

alt text

Read a WPF book: The best book I read so far is Windows Presentation Foundation Unleashed by Adam Nathan. WPF has a steep learning curve compared to Windows Forms, even for experienced C#/WinForms programmers. It has a lot of complex elements to understand like XAML, dependency properties, bindings, templates, animation, resources, etc. This book teaches you the basics gradually and is easy to read and understand. And it's in full color!

alt text

Read about the Model-View-ViewModel pattern: I haven't found a good book on that yet, but it's been very important for me to make my WPF applications more simple and manageable. My favorite material to learn about MVVM is this one hour presentation by Jason Dolinger. He builds a WPF application from scratch using no particular pattern, and step by step, migrates it to the MVVM pattern.

I would add unit testing, TDD, and mocking frameworks to your list of things to know.

I have "The Art of Unit Testing" and found it helpful.

I am looking for possibly a study between the time difference of regular coding vs coding + unit tests (not strict TDD just yet). I know the whole "Saves you time in the long run" angle, but from a project planning perspective for the team that has never done it before, I need to be able to roughly estimate how much additional time to allocate.

Does such a study exist? Can anyone comment from experience?

As someone who is currently working on his first project using unit tests (not full-blown TDD, but close), I would say that you should double the time it would usually take for your team to do their initial implementation.

Roy Osherove's book, The Art of Unit Testing, has an informal study that shows this, but also shows that when QA cycles are included, the overall release time was slightly lower when using unit tests, and there were far fewer defects in the code developed with unit tests.

I would make these suggestions:

  • Have your programmers read everything they can get on unit tests and TDD, especially anything they can find on how to design code that is test friendly (use of dependency injection, interfaces, etc.). Osherove's book would be a great start.

  • Start evaluating unit testing frameworks (NUnit, xUnit, etc.), and Mocking frameworks (Rhino Mocks, Moq, etc.), and have them choose ones to standardize on. The most popular are probably NUnit and Rhino Mocks, but I chose xUnit and Moq.

  • Don't let your programmers give up. It can be tough to change your mindset and overcome the natural resistance to change, but they need to work through that. Initially it may feel like unit tests just get in the way, but the first time they refactor sections of code on the fly and use unit tests to know they didn't break anything as opposed to hoping they didn't will be a revelation.

  • Finally, if possible, don't start unit tests on a large, high-pressure project with a tight deadline; this would likely lead to them not overcoming their initial difficulties and ditching unit tests in favor of just getting the code done.

Hope this helps!

I've got a big project written in PHP and Javascript. The problem is that it's become so big and unmaintainable that changing some little portion of the code will upset and probably break a whole lot of other portions.

I'm really bad at testing my own code (as a matter of fact, others point this out daily), which makes it even more difficult to maintain the project.

The project itself isn't that complicated or complex, it's more the way it's built that makes it complex: we don't have predefined rules or lists to follow when doing our testing. This often results in lots of bugs and unhappy customers.

We started discussing this at the office and came up with the idea of starting to use test driven development instead of the develop like hell and maybe test later (which almost always ends up being fix bugs all the time).

After that background, the things I need help with are the following:

  1. How to implement a test framework into an already existing project? (3 years in the making and counting)

  2. What kind of frameworks are there for testing? I figure I'll need one framework for Javascript and one for PHP.

  3. Whats the best approach for testing the graphical user interface?

I've never used Unit Testing before so this is really uncharted territory for me.


Edit: I've just had a quick look through the first chapter of "The Art of Unit Testing" which is also available as a free PDF at the book's website. It'll give you a good overview of what you are trying to do with a unit test.

I'm assuming you're going to use an xUnit type framework. Some initial high-level thoughts are:

  1. Edit: make sure that everyone is is agreement as to what constitutes a good unit test. I'd suggest using the above overview chapter as a good starting point and if needed take it from there. Imagine having people run off enthusiastically to create lots of unit tests while having a different understanding of what a "good" unit test. It'd be terrible for you to out in the future that 25% of your unit tests aren't useful, repeatable, reliable, etc., etc..
  2. add tests to cover small chunks of code at a time. That is, don't create a single, monolithic task to add tests for the existing code base.
  3. modify any existing processes to make sure new tests are added for any new code written. Make it a part of the review process of the code that unit tests must be provided for the new functionality.
  4. extend any existing bugfix processes to make sure that new tests are created to show presence and prove the absence of the bug. N.B. Don't forget to rollback your candidate fix to introduce the bug again to verify that it is only that single patch that has corrected the problem and it is not being fixed by a combination of factors.
  5. Edit: as you start to build up the number of your tests, start running them as nightly regression tests to check nothing has been broken by new functionality.
  6. make a successful run of all existing tests and entry criterion for the review process of a candidate bugfix.
  7. Edit: start keeping a catalogue of test types, i.e. test code fragments, to make the creation of new tests easier. No sense in reinventing the wheel all the time. The unit test(s) written to test opening a file in one part of the code base is/are going to be similar to the unit test(s) written to test code that opens a different file in a different part of the code base. Catalogue these to make them easy to find.
  8. Edit: where you are only modifying a couple of methods for an existing class, create a test suite to hold the complete set of tests for the class. Then only add the individual tests for the methods you are modifying to this test suite. This uses xUnit termonology as I'm now assuming you'll be using an xUnit framework like PHPUnit.
  9. use a standard convention for the naming of your test suites and tests, e.g. testSuite_classA which will then contain individual tests like test__test_function. For example, test_fopen_bad_name and test_fopen_bad_perms, etc. This helps minimise the noise when moving around the code base and looking at other people's tests. It also has then benefit of helping people when they come to name their tests in the first place by freeing up their mind to work on the more interesting stuff like the tests themselves.
  10. Edit: i wouldn't use TDD at this stage. By definition, TDD will need all tests present before the changes are in place so you will have failing tests all over the place as you add new testSuites to cover classes that you are working on. Instead add the new testSuite and then add the individual tests as required so you don't get a lot of noise occurring in your test results for failing tests. And, as Yishai points out, adding the task of learning TDD at this point in time will really slow you down. Put learning TDD as a task to be done when you have some spare time. It's not that difficult.
  11. as a corollary of this you'll need a tool to keep track of the those existing classes where the testSuite exists but where tests have not yet been written to cover the other member functions in the class. This way you can keep track of where your test coverage has holes. I'm talking at a high level here where you can generate a list of classes and specific member functions where no tests currently exist. A standard naming convention for the tests and testSuites will greatly help you here.

I'll add more points as I think of them.


You should get yourself a copy Working Effectively with Legacy Code. This will give you good guidance in how to introduce tests into code that is not written to be tested.

TDD is great, but you do need to start with just putting existing code under test to make sure that changes you make don't change existing required behavior while introducing changes.

However, introducing TDD now will slow you down a lot before you get back going, because retrofitting tests, even only in the area you are changing, is going to get complicated before it gets simple.

On my search for a Unit-Testing tool for C# i have found xUnit.NET. Untill now, i read most of the articles on and even tried out the examples given at How do I use

But sadly, on the offical page i could just find the basic informations to xUnit.NET. Is there any further information avadible for it?

Besides the xUnit-1.9.1.chm-File mentioned by Sean U and the Examples on the official xUnit.NET website I found two other resources to help me understand the basics of the work with xUnit.NET:

Sadly, as pointed out also by Sean U, it seems as there are no books at all about the xUnit.NET-Framework yet. So, for further information it looks like one has go with studying the *.chm-File and reading general books about unit testing. Or switch to another testing-framework, that's what I think I'll do...


Ognyan Dimitrov added some additional resources in his comments:

If you decide to abandon xUnit and use NUnit instead, a good book to read is "The Art of Unit Testing (with examples in .NET)".

Nice clear explanations of both basic and advanced unit testing concepts, using the NUnit framework.

I code for a while now and learned several programming languages. I programmed a lot of little tools and such. I think I master the act of coding itself pretty good so I have e.g. no problems with syntax, I got a pretty good understanding of what is going on under the hood (reasonable assembler knowledge) and so on.

My big problem though is: I just can't design bigger/more complex applications. I learned the principles of OOP, design patterns, learned some basic lisp programming and all stuff I could find and thought it would help me with my issue.

But no matter what I try, how long I try: I just can't get it right. My designs always seem wrong to me somehow. Cause of that I never drawn through a bigger project, i'm kinda never satisfied with the structure of my program.

Have you had a similiar problem? How did you manage to solve it? Got you any hints for me on how to go on?

Design itself is an iterative activity. You first start with a certain design and then in phases you make it better.

Design is not about achiveing perfection, which can't even be achieved in larger application. Design is all about making good balances and tradeoffs that in the end provide a good, robust and maintainable application, that conforms to the requirements.

You will never get it 100% right on all sides.

Reading a few good books on design/architecture will not make you directly a rock star on the matter but it will certainly give you the tools that you can use to improve and perfect your skills.

Here are some examples of books:

Of course practical experience also counts.

Although there are plenty of resources, even here on SO, only two of the terms are compared to each other in these Q/A.

So, in short, what is each one of them? And how they all relate to each other? Or don't they at all?

Difference between mock and stub is very simple - mock can make your test fail, while stub can't. That's all there is. Additionally, you can think of stub as of something that provides values. Nowadays, fake is just a generic term for both of them (more on that later).


Let's consider a case where you have to build a service that sends packages via communication protocol (exact details are irrelevant). You simply supply service with package code and it does the rest. Given the snippet below, can you identify which dependency would be a stub and which mock in potential unit test?

public class DistributionService
    public double SendPackage(string packageCode)
        var contents = this.packageService.GetPackageContents(packageCode);
        if (contents == null)
            throw new InvalidOperationException(
                "Attempt to send non-exisiting package");

        var package = this.packageBuilder.Build(contents);

It's fairly easy to tell that packageBuilder simply provides value and there's no possible way it could make any test fail. That's a stub. Even though it might seem more blurry, packageService is stub too. It provides a value (what we do with the value is irrelevant from stub's point of view). Of course, later we'll use that value to test whether exception is thrown, but it's still all within our control (as in, we tell stub exactly what to do and forget about it - it should have no further influence on test).

It gets different with packageDistributor. Even if it provides any value, it's not consumed. Yet the call to Send seems to be pretty important part of our implementation and we'll most likely want to verify it is called.

At this point we should get to a conclusion that packageDistributor is a mock. We'll have a dedicated unit test asserting that Send method was called and if for some reasons it wasn't - we want to know that, as it's important part of the entire process. Other dependencies are stubs as all they do is provide values to other, perhaps more relevant pieces of code.

Quick glance at TDD

Stub being stub, could be just as well replaced with constant value in naive implementation:

var contents = "Important package";
var package = "<package>Important package</package>";

This is essentially what mocking frameworks do with stubs - instruct them to return configurable/explicit value. Old-school, hand-rolled stubs often do just that - return constant value.

Obviously, such code doesn't make much sense, but anyone who ever done TDD surely seen bunch of such naive implementations at the early stage of class development. Iterative development that results from TDD will often help identify roles of your class' dependencies.

Stubs, mocks and fakes nowadays

At the beginning of this post I mentioned that fake is just a generic term. Given that mock can also serve as stub (especially when modern mocking frameworks are concerned), to avoid confusion it's good idea to call such object a fake. Nowadays, you can see this trend growing - original mock - stub distinction is slowly becoming a thing of the past and more universal names are used. For example:

  • FakeItEasy uses fake
  • NSubstitute uses substitute
  • Moq uses mock (name is old, but no visible distinction is made whether it's stub or mock)

References, further reading

Before I get pointed to one of those 'VS.' questions like below...

... please let me state that I'm not looking for a comparison.

Some of my concerns that I need answers for include:

  1. Is the learning curve for doing crazy UIs (e.g. having UI for building a BOM tree online) steep? Lots of people posting questions seem to be having problems with some UI requirement or another which has me worried. Is the technology mature enough to handle those type of requirements?
  2. Is there a pretty well developed community and how available is online literature? You can get tons of literature for WebForms.
  3. Would the time to develop it be comparable or less to building a traditional enterprise WebForms site?
  4. How long would it take to get a whole team of developers comfortable (if not enamored) with WebForms to become well versed in ASP.NET MVC?

The truth of it I think is that StackOverflow is Google-like product and ASP.NET MVC might be great for that. But I'm stuck developing software in the Your company's app category.

alt text

So taking a plunge could prove very costly later on if something can't be done or it has to be hacked. Hope to hear from those that have taken the plunge.


About 3 months ago, I was told that I needed to develop an enterprise web-app (well, a series of small web-apps actually), but that I could choose whatever technology I wanted.

Since I'm most comfortable with VS/C#/.Net, the dilemma was whether to choose ASP.NET WebForms or ASP.NET MVC2 -- Unlike you, my only background was with Windows Forms (WinForms) and a little WPF. So I had to research (and try-out) both WebForms and MVC.

Just like you, I realized that my app would be neither Google nor Apple like, but your bog standard company app with thousands of buttons and boxes, etc. WebForms seemed like it would be the fastest to deploy, but hard to test and hard to maintain on a long-term basis. MVC seemed to have a much steeper learning curve, but once established, testing and maintenance would be a breeze.

I only fiddled with WebForms for a week, so I can't really comment on it. But MVC is definitely everything I was expecting it to be.

Yes, it's a steep learning curve. Concepts that were new to me:

  • Model-View-Controller (MVC)
  • Separation of Concerns (SoC)
  • Model Binding
  • Unit Testing and Test Driven Design (TDD)
  • Mocking and Stubbing
  • Dependency Injection (DI)

The books that helped me the most were:

I also had to brush up on my HTML, CSS, and Javascript.

Overall, there seems to be a fair amount of ramp-up work in the beginning, but maintaining and extending the existing application has been pretty painless. Whenever I've been asked to make changes, it's been fairly easy and I've typically been able to deliver on-time or even sometimes ahead of schedule.

In an ideal world, writing an MVC app would happen with 2 people. One person writing the core code and a second person writing the UI and the Views (HTML, CSS, Javascript.) Although it's entirely possible to do it all by yourself. (which is what I'm doing right now...)

I have run into some hitches deploying in the Enterprise, though. Internally, my company is running Windows Server 2003 and IIS6. Unfortunately, we have been unable to get the app to deploy properly on IIS6 when using Virtual Pathing. (All the references to and in the CSS files are broken.) If you plan on deploying MVC, I would recommend using IIS7 or higher. MVC supposedly works on IIS6, but requires that your IT department be willing to figure out how to get it to work.

Edit: I just realized I never directly answered your questions. Here goes:

  1. My personal experience has said, that, yes, the learning curve is steep for building good Models and UIs, but I'm not really a web-developer so I've been working with that handicap. The good news is that the MVC technology is pretty mature.

  2. Yes, the community is pretty well developed and growing. You'll get a lot of good answers from StackOverflow as well as MS's ASP.NET MVC sub-forum.

  3. I have no personal experience coding WebForms, but I have coded plenty of WinForms apps and I feel like it's taken me approx. 3 times longer to build this MVC app. The initial investment is a bear, but regular maintenance and improvements seem to come WAY faster, especially as the app has grown... Since you seem to have a team of programmers, it may come faster for you guys as you can probably split up the learning/workload.

  4. Again, no prior experience with WebForms, but what I can tell you is that as I was learning ASP.NET MVC, there were times when I was struggling to understand what was going on because I had no prior ASP.NET background. (Example: Membership and Role Providers -- I had to code my own recently. Boy was that fun...) On the plus side, I didn't have any "old ways of doing things" (aka. WebForms) to unlearn either. If you have a team of folks enamored with PostBack / CodeBehind, you can bet that MVC is gonna seem awfully strange at first. But hopefully your team will see the advantages that MVC brings and embraces it fully.

Oh, and it should be noted that you can blend MVC and WebForms. It's not an all-or-nothing proposition. Although, if I were in your shoes, I'd try to embrace MVC as much as possible and only use WebForms where it clearly makes more sense.

Ok, I hope this helps... :-)

I just bought The Art of Unit Testing from Amazon. I'm pretty serious about understanding TDD, so rest assured that this is a genuine question.

But I feel like I'm constantly on the verge of finding justification to give up on it.

I'm going to play devil's advocate here and try to shoot down the purported benefits of TDD in hopes that someone can prove me wrong and help me be more confident in its virtues. I think I'm missing something, but I can't figure out what.

1. TDD to reduce bugs

This often-cited blog post says that unit tests are design tools and not for catching bugs:

In my experience, unit tests are not an effective way to find bugs or detect regressions.


TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests. That’s all!

Makes sense. The edge cases are still always going to be there, and you're only going to find the superficial bugs -- which are the ones that you'll find as soon as you run your app anyway. You still need to do proper integration testing after you're done building a good chunk of your software.

Fair enough, reducing bugs isn't the only thing TDD is supposed to help with.

2. TDD as a design paradigm

This is probably the big one. TDD is a design paradigm that helps you (or forces you) to make your code more composable.

But composability is a multiply realizable quality; functional programming style, for instance, makes code quite composable as well. Of course, it's difficult to write a large-scale application entirely in functional style, but there are certain compromise patterns that you can follow to maintain composability.

If you start with a highly modular functional design, and then carefully add state and IO to your code as necessary, you'll end up with the same patterns that TDD encourages.

For instance, for executing business logic on a database, the IO code could be isolated in a function that does the "monadic" tasks of accessing the database and passing it in as an argument to the function responsible for the business logic. That would be the functional way to do it.

Of course, this is a little clunky, so instead, we could throw a subset of the database IO code into a class and give that to an object containing the relevant business logic. It's the exact same thing, an adaptation of the functional way of doing things, and it's referred to as the repository pattern.

I know this is probably going to earn me a pretty bad flogging, but often times, I can't help but feel like TDD just makes up for some of the bad habits that OOP can encourage -- ones that can be avoided with a little bit of inspiration from functional style.

3. TDD as documentation

TDD is said to serve as documentation, but it only serves as documentation for peers; the consumer still requires text documentation.

Of course, a TDD method could serve as the basis for sample code, but tests generally contain some degree of mocks that shouldn't be in the sample code, and are usually pretty contrived so that they can be evaluated for equality against the expected result.

A good unit test will describe in its method signature the exact behavior that's being verified, and the test will verify no more and no less than that behavior.

So, I'd say, your time might be better spent polishing your documentation. Heck, why not do just the documentation first thoroughly, and call it Documentation-Driven Design?

4. TDD for regression testing

It's mentioned in that post above that TDD isn't too useful for detecting regressions. That's, of course, because the non-obvious edge cases are the ones that always mess up when you change some code.

What might also be to note on that topic is that chances are good that most of your code is going to remain the same for a pretty long time. So, wouldn't it make more sense to write unit tests on an as-needed basis, whenever code is changed, keeping the old code and comparing its results to the new function's?

I believe the benefit of TDD is that you actually write the tests as they are more interesting when they are a goal you have to achieve, (create code to pass the tests), rather than a chore you have to do afterwards.

Also, it puts you in the mind of the user. You have to think "so what does the user need my method to do" or whatever, rather than, "I hope my method has achieved what it was supposed to do". In this way, it may also help to reduce bugs.

Example class in pseudocode:

class SumCalculator
  method calculate(int1, int2) returns int

What is a good way to test this? In other words how should I describe the behavior I need?

test1: canDetermineSumOfTwoIntegers


test2: returnsSumOfTwoIntegers


test3: knowsFivePlusThreeIsEight

Test1 and Test2 seem vague and it would need to test a specific calculation, so it doesn't really describe what is being tested. Yet test3 is very limited.

What is a good way to test such classes?

There are several philosophies. Roy Osherove, author of The Art of Unit Testing, seems to prefer using explicit values, and selecting the lowest (or simplest) representation of each Equivalence Class.

That principle doesn't apply itself particularly well to your example, but works really well in many other scenarios.

If, for example, a class requires an input of a positive integer, you pick the number 1 because it's the simplest representation of all positive intergers.

Personally, I rather prefer a principle I call Constrained Non-Determinism. The point here is that we let some kind of factory serve us anonymous variables for the given type, because it forces us to establish the relationship directly in the test.

I'm using AutoFixture to do this (but you could also use something else), so in this case I would test the SumCalculator like this:

var fixture = new Fixture();
var int1 = fixture.CreateAnonymous<int>();
var int2 = fixture.CreateAnonymous<int>();
var expectedResult = int1 + int2;
var sut = fixture.CreateAnonymous<SumCalculator>();

var result = sut.Calculate(int1, int2);

Assert.AreEqual(expectedResult, result);

In principle, this single test provides a specification for the Calculate method. We never know what the values of int1 and int2 are, and that is very appropriate in all those many cases where it actually doesn't matter.

I want to learn how to build “robust” software that is designed to test itself. In other words, how do I implement automated tests in my software ( using java or groovy or c++ ).

So I want to know where to learn this (books or websites) and which tools and libraries I will need for this?

I found The Art of Unit Testing by Roy Osherove to be very helpful in understanding the basics of unit testing, integeration testing, TDD and so on. It's a bit tailored for .Net languages, but it also provides very good information on the ideas behind automated testing.

Look at the xUnit testing frameworks (cppUnit for C++, JUnit for Java) and check out the wonderful book xUnit Test Patterns: Refactoring Test Code.

And if you really want to get into it, check out test-driven development. A good introduction is Uncle Bob's The Three Laws of TDD and the bowling game kata (see also bowling game episode). A great book on the subject is Test Driven Development: By Example.

I am using Microsoft Unit Test and have the following:

public class AccountCommandHandlers :
    public bool CreateAccountCommandWasCalled = false;
    public bool CloseAccountCommandWasCalled = false;

    public void Handle(CreateAccountCommand command)
        CreateAccountCommandWasCalled = true;

    public void Handle(CloseAccountCommand command)
        CloseAccountCommandWasCalled = true;

public void CanRaiseInternalHandlers()
    var iocContainer = SimpleInjectorWiringForMembus.Instance;

    var membus = MembusWiring.Instance;

    membus.Bus.Publish(new CreateAccountCommand() { Id = 100 });
    membus.Bus.Publish(new CloseAccountCommand() { Id = 100 });

I am using an IoC container (Simple Injector) which handles the lifetime scope of objects. Membus wires up commands to command handlers, and resolves via the IoC container.

The above code runs and works and the command handlers set their local variables to true.

However, since Simple Injector handles the lifetime scope, I cant ask Simple Injector for an AccountCommandHandler object as it would return a new object with CreateAccountCommandWasCalled set to false.

Being new to Unit Testing what would be a more robust way to test other than setting CreateAccountCommandWasCalled as a static variable?

Here's a more "philosophical" answer to your question :-)

My recommendation would be to not use the IOC container in your testing at all, if possible!

My rationale is that you need your test to have full control over the context of the test, and an IOC can take away some of this control. IMO, unit tests should be as focussed, small and predictable as possible!

Consider sending mock objects into your class under test, instead of actual classes.

If your class needs to have an internal instance of an IOC container, factor this out of the class into a "controller" of some sorts.

You could accomplish this in several ways, my favourite being using a framework like Rhino Mocks.

This way, you would actually stub out the "lifecycle" provided by the IOC at run time, in your test "setup".

So the test should have full control (through mocking and stubbing) over when objects are created or destroyed, using a framework like Rhino.

You could mock out the IOC, if this is even needed.

As a side note, one of the benefits of a well designed IOC container is that it should make unit testing easier - because it should discourage classes from relying on actual "concrete instances" of classes, and encourages the use of interchangeable interfaces instead.

You should try rely at run time on the IOC container providing the concrete implementations of the interfaces you've designed against.

Note that it's also normally important to get clarity about what you are actually testing. Unit tests should typically focus on testing the behavior of a single method on a single class.

If you're actually testing "more" than just one method on one class, for e.g. how a class interacts with other classes, it means you're most likely writing an "integration" test, not a true "unit" test.

Another note: I don't claim to be an expert at unit testing! They are incredibly useful, but I still struggle with testing more than almost any other aspect of coding.

For further reading, I highly recommend "The Art of Unit Testing" by Roy Osherove. There are others too.

The Art of Unit Testing

Is it possible to do TDD on MVC 3? And if so, what are some good online resources? As far as I know, MVC 3 is the latest version that is out. But most of the tdd articles I google are for MVC 1. Even the only two books I've been able to find on TDDing in MVC are both for 1.0 MVC Test Driven Development

Test Drive MVC

Even on the official Microsoft website the article that's an MVC TDD walkthrough is for MVC 2.0.

It's starting to make me think TDD is just not practical on MVC or that it's not heavily supported.

This is the best resource I know for learning TDD:

Roy Osherove - The Art of Unit Testing

After reading this and reading the following MVC3 book:

Sanderson and Freeman - Pro ASP.NET MVC3 Framework

With this you will know enough to get started with Test Driven Development in MVC3.

I find the concept of partitioning the statements of my unit tests as suggested in the AAA pattern useful.

I tend to add heading comments so that the tests look like this:

// Arrange
int a = 1;
int b = 2;

// Act
int c = a + b;

// Assert
Assert.AreEqual(3, c);

But I am curious, is it normal to always include these header comments?

...or is this something which I should avoid?

int a = 1;
int b = 2;

int c = a + b;

Assert.AreEqual(3, c);

That doesn't seem to add much value once the basic premise is understood. Since you mention C#, I suggest taking a look at The Art of Unit Testing for examples. Naming a unit test correctly is more important IMHO than arrange/act/assert comments within it. As the book points out, when a test fails, if it is named well you can often deduce the cause of a regression directly if you know what changes were made recently.

Jimmy Bogard, wrote an article: Getting value out of your unit tests, where he gives four rules:

  • Test names should describe the what and the why, from the user’s perspective
  • Tests are code too, give them some love
  • Don’t settle on one fixture pattern/organizational style
  • One Setup, Execute and Verify per Test

In your opinion these guidelines are complete? What are your guidelines for unit tests? Please avoid specific language idioms, try to keep answers language-agnostic .

There's an entire, 850 page book called xUnit Test Patterns that deal with this topic, so it's not something that can be easily boiled down to a few hard rules (although the rules you mention are good).

A more digestible book that also covers this subject is The Art of Unit Testing.

If I may add the rules I find most important, they would be:

  • Use Test-Driven Development. It's the by far the most effective road towards good unit tests. Trying to retrofit unit tests unto existing code tend to be difficult at best.
  • Keep it simple: Ideally, a unit test should be less than 10 lines of code. If it grows to much more than 20 lines of code, you should seriously consider refactoring either the test code, or the API you are testing.
  • Keep it fast. Unit test suites are meant to be executed very frequently, so aim at keeping the entire suite under 10 s. That can easily mean keeping each test under 10 ms.

Can you recoment a book on on Unit Testing and TDD for C# with at least some treatment of Mock Objects?

I have seen this question but it does not seem to mention mocking.

The Art of Unit Testing: With Examples in .NET by Roy Osherove (Amazon Page, Official Site) sounds like what you're looking for. He devotes one chapter introducing the concepts of stub and mock objects (using a "roll-your-own" approach), and then a second chapter on using mock object frameworks, particularly Rhino Mocks. There is somewhat less emphasis on Test-Driven Development, but there is quite a lot of information about TDD available from other sources, and TDD isn't all that language-specific.

Hello I am struggling with simple problem.

General idea:

class Foo(){
  public boolean method1();
  public String method2();
  public String method3();
  public String shortcut(){
    return (method1() == true) ? method2() : method3();

How should I test shortcut method?

I know how to mock objects and test methods that use other object. Sample:

class Car{
  public boolean start(){};
  public boolean stop(){};
  public boolean drive(int km){};
class CarAutoPilot(){
  public boolean hasGotExternalDevicesAttached(){
     //Hardware specific func and api calls
     //check if gps is available 
     //check if speaker is on
     //check if display is on 
  public boolean drive(Car car, int km){
    boolean found = hasGotExternalDevicesAttached();
    boolean start = c.start();
    boolean drive =;
    boolean stop = c.stop();
    return (found && start && drive && stop) == true;   

class CarAutoPilotTest(){
   public void shouldDriveTenKm(){
     Car carMock = EasyMock.Create(Car.class);

     CarAutoPilot cap = new CarAutoPilot();
     boolean result =,10);

But what about hasGotExternalDevicesAttached() method? This is only sample not real scenario. How should I test drive method? Should I also mock hasGotExternalDevicesAttached function?

Can I mock class that is being tested?

I would create one test for each method. If you lower the complexity then it is much easier to test.

these should have one test each:

  public boolean method1();
  public String method2();
  public String method3();

There is no need to test the last method since it calls your other methods, how ever, if that method changes (since im guessing its only a sample code) and it has more logic in it then you should have one test method for that as well.

When it comes to the hasGotExternalDevicesAttached() you should create a mocker for all external io calls that you cant test.

If you want to improve your skill within testing I would recommend that you read The Art of Unit Testing. This is in my opinion the best book for beginners to learn and study the art of unit testing.

I am reasonably new to WPF and MVVM but I understand the basics. The problem I am having is trying to find some good resources to learn unit testing with MVVM. I am new to unit testing.

Can anyone recommend some good resources whether it's blogs, videos, or even books.

The Art of Unit Testing is good book for you. And Moq for mocking framework

I'm starting to use test driven development for JavaScript, but I would like to start using it in my different projects.

I would like to know what are the typical mistakes and how to avoid them?

Also, I would like to know what I should read to make test driven development easier to learn and apply to my code.

Thanks in advance.

The single biggest issue I've faced using TDD is developers not being confident about unit testing. Poor unit testing wastes more time than it saves. Confused, untrustworthy, unmaintainable, unreadable tests fall by the wayside very quickly and jaded developers take time to want to unit test automatically again.

Per Fagrell makes some good points, especially about running the tests after every change; it should become second nature to run the tests before and after any test change.


Consider QUnit as your framework for JS testing:

I've got a test harness page with the dependent mark up and the tests run at page load very well.

You can follow the

  • Arrange
  • Act
  • Assert

flow for unit tests using QUnit.

However, you will have to manually have to implement test setup and teardown methods and call them in your test methods. These will help with the isolation of test cases by keeping the conditions indentical for all tests and prevent tests being dependent on the ordering of their running.

Look for useful frameworks in the other languages you will be using. NUnit is very popular for .NET.


Per Fagrell also makes a good point about isolation. The distinction between unit testing (testing one aspect of atom of functionality) and integration (testing how multiple atoms work together) should be thoroughly understood before beginning testing. If you have more than one assert in a test method, you are not unit testing and need to change your test method.


A good naming convention from the excellent The Art Of Unit Testing for your tests is MethodUnderTest_Condition_ExpectedBehaviour e.g.


From the same book keep your tests:

  • Trustworthy
  • Maintainable
  • Readable

Otherwise you and other developers will not bother running the tests.


A common misunderstanding is the difference between the two types of fakes: stubs and mocks.

A seam is created in code by abstracting functionality that code depends on into an interface. E.g. A controller doesn't depend on a concrete repository, it will depend on an IRepository.

A stub then implements this IRepository and returns faked values; it is used to isolate the controller code to run in isolation. e.g. GetCustomer() will create a new customer and return that, with no calls to the real repository or any store. Stubs are never tested against.
A mock is like a stub except that it can hold values which can be tested against. e.g. AddCustomer(Customer customerToBeAdded), your mock will accept that value and can be asserted against. Mocks can be tested against.

Have a look at a Test Isolation Framework (or Mocking Framework), that can automatically create fakes for a given Interface.

A misunderstanding of the purpose of mocks has lead to more than one developer that I have seen create a mock to test functionality and then write tests against the mocks themselves.


I've mentioned The Art Of Unit Testing and I recommend it thoroughly. It is one of the books, along with Code Complete, that I would grab if the office caught fire.

Hope that helps.

I've searched for this info and see similar questions, but not one that matches very closely to this. If I missed one, I apologize. I was hoping that you'd be able to point me in a direction. I'm working on a Silverlight based project and my team is finally moving toward implementing unit testing. I and another memeber of my team are responsible for recommending a unit testing framework for the project. Our basic criteria are:

  1. The project contains standard ASMX .NET webservices and a Silverlight front end. We'd prefer, if at all possible, to maintain the same test attributes throughout, rather than use one set for Silverlight tests and another for other code.

  2. Integration with VS 2008 is fairly important. We'd like to keep it all under one roof if that's feasible. We'd be happy with simply being able to kick the unit test off from VS.

  3. Automated build/checkin testing. We are currently working in a completely non-automated VS 2008/VSS 2005 environment. We are in the process of converting to SVN for source control and our corporate office will be assisting us in using MSBuild to automate the build process. We'd certainly prefer to be able to integrate into this environment as much as possible. I'm not certain as to the details of this process as yet since I'm not directly involved. If there is more detail that you need on this, please let me know and I'll see what I can find out.

At this point, my collegue and I are looking at NUnit (along with possble Silverlight options) and MSTest in conjunction with the Silverlight Testing Framework that Jeff Wilcox wrote. While the corpoarate standard is NUnit, they are open to other options as there aren't any other teams doing Silverlight work.

I'm about halfway through Roy Osherove's Unit Testing Book, so I'm getting a feel for writing tests in general. I'm not married to a particular framework, but corporate seems to be most open to NUnit or MSTest. I'd also like to get my hands on a good tutorial of MSTest, if possible.

Thanks for taking the time. If you need any other info from me, feel free to ask.



Tread carefully, and make sure to experience these possibilities first. It's easiest to know what you're looking at by writing a few tests in each, and figure out what your workflow will be.

The Silverlight unit test systems out there are less mature than the officially shipped, full-fledged test frameworks for the desktop .NET environment, so your experience may vary. Understand that the Silverlight test solutions in place today (that actually run inside of a web browser) exist to specifically help folks get coverage of their code and components within the context of the Silverlight platform, and not necessarily for rapid, or easy, test-driven development and testing that you can get through the integrated Visual Studio tools.

The sandboxed security model for Silverlight makes many of the standard testing tools you may expect much more difficult.

It's also a different platform, really, so it may not make sense to perform every kind of test (example: a "load test" for a web app... you can "stress" a Silverlight app, or look into its "performance", but a "load test" is about stressing your machine that hosts the .XAP file, and is not very interesting for Silverlight apps specifically).

If you're more concerned about testing your business logic and having nice integration, strongly consider writing mockable/IoC code enough that you may be able to develop most of your app and test a version of it built as a regular desktop .NET class library ~ you could then have a subset of tests that are Silverlight in-browser only.

To your notes:

  • Are you actually going to be testing the web service calls with your tests? This sort of integration/client + server testing can be very, very difficult to do properly between Silverlight client code and a web service.

  • You won't get much integration with Visual Studio 2008's IDE for the Silverlight unit test framework. You can have a Silverlight test project / app that you can press F5 to open, and debug, in Visual Studio and run the tests. However, you won't have right-click "Run All Tests" or test case management tools working.

  • Automated test check-in for the Silverlight unit testing framework is something that is developing slowly, some folks have written a set of Silverlight test runners on CodePlex. You may not get this easily, and your build/test machine will need to be setup so that the build service runs instead as an actual user process, so that it can open and control web browser(s)

In the future, on the Silverlight Toolkit team, we are going to release some level of automated test support in the future, along with simple code coverage support, but these tools are not readily available as of today (Oct. '09)

I'm looking for a good introduction/tutorial for unit testing C#. Most tutorials I've come across so far have either been too basic to be useful or too complex for someone new to unit testing.

(Using Visual Studio 2008 Professional for Windows applications)

Read The Art of Unit Testing by Roy Osherove. It is very good. alt text

What .net/c# focused books are there that teach how to develop applications using SOLID principles, unit testing, IoC, etc?

I've watched a few videos on the SOLID principles, but I'd love to learn more about it and in detail on how to go about designing larger scale applications etc.

First of all, it is this book:

Robert Martin - it is a person who introduced SOLID principles.

And I am looking forward to read this book about DI in .Net:

About unit testing here is very good book:

I have read/watched so much about TDD & BDD recently that I really want to master it. I have been a developer that only writes code and then tests it from outside (like we always started). The problem seems to be in getting up and running with TDD. I want to just create a simple Winform app in which I want to show a list of something lets say products. I just don't know where to get started, should I write a test for controller first? the controller needs reference to view and service and so on so forth. ASP.Net MVC is built for testing therefore it is a bit easy to get started but Winforms are a real pain. Kindly give me some Videos (Most preffered) that show TDD in Winforms.

I have watched tons of videos that show you testing a class or feature but how do you test UI that does not support testing?

In short I want to know if anyone has been doing TDD for a while, how does he/she do it in Winforms?

I have written loads of code that I just delete because I get stuck, Please help!

I'm new to TDD too, and just like you I'm trying to learn. Here's what I've come up with during my searches, maybe it will help you too:

  1. Check out Roy Osherove's website, and also his book "The Art of Unit Testing". Check out the videos, there are some great ones, especially the "Pair Programming" section. His book was the single best book that I've read about unit testing and TDD, and the only one that I've read from cover to cover.
  2. Check out some TDD katas. There are some on the web page I've suggested in the previous item. Check out how other people are solving the katas. It's really helpful.
  3. Read about dependency injection.
  4. If you want to TDD in WinForms, check out the MVP pattern. As far as I know, it's the de facto patten for separating UI from business code in WinForms.

Good luck with your search.

I need to write a unit test for a method where I arrange data according to another default list.

This is the method.

internal AData[] GetDataArrayInInitialSortOrder(ABData aBData)
    Dictionary<string,AData > aMap = aBData.ADataArray.ToDictionary(v => v.GroupName, v => v);
    List<AData> newDataList = new List<AData>();
    foreach (AData aData in _viewModel.ADList)
    return newDataList.ToArray();

Please help I am new in unit testing and this is not easy for me.

I've set up a test database to begin unit-testing an app that I've recently been added to. It is a 3-tier design (presentation layer, BOL and DAL) and this is my first time writing unit tests.

I've decided to start at the BOL and I figure the best way is to swap out the ConnectionString (which has been passed along as a Shared String) with one that points to my new test database. However, I don't wish to change any production code. I simply wish to somehow redirect the app to the test database during unit tests. How might I go about accomplishing this?

As you will probably soon learn anyway, static/Shared code is considered evil in unit testing, for a number of reasons. One of these reasons is that it is difficult to change the values during unit testing.

It is a much better idea to pass your Dependencies explicitly to your System Under Test (SUT) - preferably in the constructor. In your case, you should pass the connection string to the SUT via its constructor.

An even better approach would be to abstract away the Data Access Layer behind an interface and pass an instance of that interface to the SUT.

I've written a bit about Imperative Configuration, but in general, you should read Roy Osherove's book The Art of Unit Testing - it deals with a lot of these issues.

Sometimes when you deal with legacy code you find it hard to break the dependencies. One of the solutions that some unit-testing gurus (e.g. Roy Osherove in The Art of Unit Testing or Michael Feathers in Working Effectively with Legacy Code) propose is to use the "Subclass and override" technique. The idea of this technique is to encapsulate the usage of dependency in protected method and then test the extended class with that method overridden with method that uses fake dependency.

Also there are two more techniques that, imo, are doing almost the same. Those are:

  • mock the protected method that contains dependency
  • use reflection (if it is supported in your language) to make the dependency-containing protected method to return what is needed

However the latter two techniques are considered to be anti-patterns (you don't mock what you are testing). But, to me, all three techniques are using the same idea. Is the "Subclass and override" technique also considered an anti-pattern and if not, why?


The phrase "you don't mock what you are testing" seems to be confusing so I should probably explain myself. Though only one method of the class is mocked, AFAIK, the fact of mocking the part of the class under test is considered to be bad practice because it breaks encapsulation and exposes implementation details to the test.

I don't understand your comment about those two more techniques.

You mock method because it is dependent on something you don't wan't in your test. You are not testing it. You are testing the rest of the code and this method (before it is mocked) prevents you from doing it.

Can anyone tell me what is NUnit in .NET and how to use it? I have heard that using this tools improves design of an application. Is it true? Where can I get an absolute beginners tutorial on this topic?

NUnit is a framework for conducting unit testing.

If you're not familiar with unit testing, "Test Infected" may be a good introduction for you. It's about jUnit (Java) rather than NUnit, but I don't think that should be too much of a problem for you.

There are lots of books on unit testing - Roy Osherove's "The art of unit testing" comes pretty highly recommended.

Hi I just started to read The Art of Unit Testing: With Examples in .Net in order to understand what unit testing is and how to properly code unit tests.

First I tought that in the book the author is going to use the integrated Unit Testing Tools from Visual Studio witch I assumed is called NUnit.I was wrong but it was no problem because the principles of unit testing should be the same in both (correct me if I am wrong)

I tryed installing NUnit on my PC witch has isntalled an x64 Windows 8.This is the code I am trying to test:

 public class LogAnalyzer {
    public bool IsValidLogFileName(string fileName) {
        if (!fileName.EndsWith(".slf")) {
            return false;
        return true;

And this is the code that does the testing:

public class LogAnalyzerTests {
    public void IsValidFileName_validFileLowerCased_ReturnsTrue() {
        LogAnalyzer analyzer = new LogAnalyzer();
        bool result = analyzer.IsValidLogFileName("whatever.slf");
        Assert.IsTrue(result, "filename should be valid");

When I try to load the dll of the test in NUnit GUI and run it I get the following error:


System.BadImageFormatException : Could not load file or assembly 'LogAnalyzer, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.

This are the steps I followed after installing NUnit:

  1. create class project
  2. add reference to the project that is tested
  3. add reference to NUnit
  4. Open NUnit GUI
  5. Load NUnitClassLibrarry.dll from debug folder
  6. Run (this is where the error appeared)

What am I doing wrong and how can I fix it?

I managed to find a solution to my curent problem aldo I do no fully understand why this works.In the folder where NUnit is installed there is an x86 version of the program and for some reason this one works.

I am not sure what I should be doing here. Should I be hardcoding all the values in or should I have them in a CONST variables. Everything I seen seems to hard code the values in so I am not sure.

Like this is what I was doing now.

Say in my controller I had a validation test to check if the user tries to submit a form with a blank field.

Now I would have a if statement checking for blank or null variable. If this happened then I would add the error to the ModelState with an error message that I wrote.

so in my unit test I want to make sure that if a blank form variable is submitted that it gets caught.

now in my unit testing I just made a CONST varible and copied in and pasted the validation message in.

So in my assert I compare what the actual message is compared to the message stored in my CONST Varrible. I do this by calling like the Model state and call the field up where I expect the error to be.



So if the message is there then it must have gone into my code otherwise it would not exist.

So it occurred to me maybe I should make a new class that will be static and hold all these CONST variables.

That way both the controller views and the unit tests can use them. That way if I got to change the error message then I only need to change it one place. Since I am not testing what the error message is I am testing if it gets set.

The same thing say for exceptions I have some custom messages but I am not testing if the message is right, more if the expection got caught.

The way I am testing it though is to see if the message is the message that I expect since if it is not the message or the message does not exist then something went wrong.

I am new to unit testing so I wanted to make sure that what I am going to do won't some how screw up my unit tests.

To me it makes sense but I thought better check first.


It's important to write each test in a way that is robust to subsequent change. You will often need to change parts of your application at a later date, and each time you do that, there's a risk that you will break one of more of your tests.

If your tests are robust to change, a failing test will truly indicate a regression bug.

However, if your tests are what's called Overspecified Tests, every little change you make in your code base may cause tests to fail - not because there was a regression bug, but because the test is too brittle. When this happens, you lose faith in your tests; test maintainance takes a lot of time, and you'll eventually end up abandoning the test suite altogether.

As I read your question, you are already beginning to see the contours of this anti-pattern. I assume that is why you don't test for the specific texts returned, but merely whether they are being set at all. I think this is correct - I rarely test for specific strings, but rather whether a string is specified at all. This makes the test more robust to change, and you avoid the Overspecified Test anti-pattern.

In many cases, instead of doing an Assert.AreEqual on two strings, you can just use Assert.IsNotNull, or perhaps Assert.IsFalse(string.IsNullOrEmpty(result)) (your platform seems to be .NET).

In general, assertions based on Derived Values are very robust to change, so you may want to take a look at the following blog post:

If you feel particularly adventurous, I can only recommend that you read xUnit Test Patterns, from where many of the patterns and anti-patterns I mention originate. The Art of Unit Testing is also good...

I am using .NET 4, NUnit and Rhino mocks. I want to unit test my news repository, but I am not sure of how to go about it. My news repository is what I will eventually be using to communicate to the database. I want to use it to test against fake/dummy data. Not sure if it is possible?? This is what I currently have:

public interface INewsRepository
   IEnumerable<News> FindAll();

public class NewsRepository : INewsRepository
   private readonly INewsRepository newsRepository;

   public NewsRepository(INewsRepository newsRepository)
      this.newsRepository = newsRepository;

   public IEnumerable<News> FindAll()
      return null;

My unit test looks like this:

public class NewsRepositoryTest
   private INewsRepository newsRepository;

   public void Init()
      newsRepository = MockRepository.GenerateMock<NewsRepository>();

   public void FindAll_should_return_correct_news()
      // Arrange
      List<News> newsList = new List<News>();
      newsList.Add(new News { Id = 1, Title = "Test Title 1" });
      newsList.Add(new News { Id = 2, Title = "Test Title 2" });

      newsRepository.Stub(r => r.FindAll()).Return(newsList);

      // Act
      var actual = newsRepository.FindAll();

      // Assert
      Assert.AreEqual(2, actual.Count());

In the above code I am not sure what I need to mock. The code above compiles but fails in the NUnit GUI about a contructor value. I can only assume it has to do with the INewsRepository paramter that I need to supply to NewsRepository. I don't know how to do this in the test. Can someone please rectify my unit test so that it will pass in the NUnit GUI? Can someone also provide some feedback on if I am implementing my repositories correctly?

Being a newbie to mocking, is there anything that I need to verify? When would I need to verify? What is its purpose? I have been working through a couple of source code projects and some use verify and some don't.

If the above test passes, what does this prove to me as developer? What does another developer have to do to my repository to make it fail in the NUnit GUI?

Sorry for all the questions, but they are newbie questions :)

I hope soomeone can help me out.

As Steven has said, you're Asserting against the Mock NewsRepository in the above code.

The idea of mocking is to isolate the Code Under Test and to create fakes to replace their dependencies.

You use the Mock NewsRepository to test something that uses INewsRepository, in your case, you mention NewsService; NewsService will use your mock of INewsRepository.

If you search your solution for anything that uses INewsRepository.FindAll(), you will create a Mock Repository to test that code in isolation.

If you want to test something that calls your Service layer, you will need to mock NewsService.

Also, as Steven as said, there is no need for the NewsRepository to have a copy of itself injected by IoC, so:

public class NewsRepository : INewsRepository
   private readonly INewsRepository newsRepository;

   public NewsRepository(INewsRepository newsRepository)
      this.newsRepository = newsRepository;

   public IEnumerable<News> FindAll()
      return null;

should become:

public class NewsRepository : INewsRepository
   public IEnumerable<News> FindAll()
      return null;

Once you have functionality in your FindAll() method that needs testing, you can mock the objects that they use.

As a point of style from the great Art Of Unit Testing initialisation of mock objects is best left out of the Setup method and carried out in a helper method called at the start of the method. Since the call to Setup will be invisible and makes the initalisation of the mock unclear.

As another point of style, from that book, a suggested unit test naming convention is: "MethodUnderTest_Scenario_ExpectedBehavior". So,

could become, for example:

I hope this makes the approach clearer.

I'm brand new to unit testing, and I'm using the VS 2010 unit testing framework.

I've got a function that grabs an integer from the user, then executes different functions based on user input. I've read a lot on unit testing but I haven't found anything that shows me how to test each branch of a switch statement. What I've got so far:

    public void RunBankApplication_Case1()
        using (var sw = new StringWriter())
            using (var sr = new StringReader("1"))
                BankManager newB = new BankManager();
                var result = sw.ToString();

                string expected = "Enter Account Number: ";

When the function under case 1 gets called, the first thing that happens is the string "Enter Account Number: " gets written to the console. However, this isn't working at all. Am I not passing input to the console correctly? Thanks for the help!

Edit: my RunBankApplication() function:


            option = GetMenuOption();

            switch (option)
                case 1:
                    if (!CreateAccount())
                        Console.WriteLine("WARNING: Could not create account!");
                case 2:
                    if (!DeleteAccount())
                        Console.WriteLine("WARNING: Could not delete account!");

                case 3:
                    if (!UpdateAccount())
                        Console.WriteLine("WARNING: Could not update account!");

                case 4: DisplayAccount();
                case 5: status = false;
                default: Console.WriteLine("ERROR: Invalid choice!");
        } while (status);

it's not right approach. You shouldn't communicate with Console in unit tests. Just extract your function which works with input parameters and test this function.

like this:

in YourExtractedClass:

      public string GetMessage(string input)
            var result = string.Empty;

            switch (input)
                case "1":
                    result = "Enter Account Number: ";
                case "2":
                    result = "Hello World!";

            return result;


In your Test class for YourExtractedClass

    public void GetMessage_Input1_ReturnEnterAccountNumberMessage()
        var result = GetMessage("1");
        var expected = "Enter Account Number: ";

        Assert.That(result == expected);

    public void GetMessage_Input2_ReturnHelloWorldMessage()
        var result = GetMessage("1");
        var expected = "Hello World!";

        Assert.That(result == expected);

And one more thing: it's better to move you strings ("Enter Account Number" etc) to one place (fro example to some Constants class). Don't repeat yourself!

read good books about unit testing:

The Art of Unit Testing: With Examples in .Net

Pragmatic Unit Testing in C# with NUnit, 2nd Edition

xUnit Test Patterns: Refactoring Test Code

This is the first time that I write a TestMethod. Am I using Unit Testing correctly ?

public void TestUpdateAccount()
    GwIntegrationServiceSoapClient client = new GwIntegrationServiceSoapClient();

    int id = 21; // Target account to update.
    Account accountToUpdate = client.ReadAccount(id);

    string oldName = accountToUpdate.Name;
    string oldEmail = accountToUpdate.Email;
    string newName = Guid.NewGuid().ToString();
    string newEmail = Guid.NewGuid().ToString() + "";

    // Update the name only, even a value is passed in newEmail 
    // But in the propertiesToUpdate parameter (last one) only Name value is passed.
    // Note: the UpdateAccountProperty could be: 
    //          [UpdateAccountProperty.Name | UpdateAccountProperty.Name.Email]
    client.UpdateAccount(id, newName, newEmail, null, false, UpdateAccountProperty.Name);

    // Read the record after updating from database
    Account updatedAccountFirstTime = client.ReadAccount(21);

    // The name should be changed
    Assert.AreEqual(newName, updatedAccountFirstTime.Name);

    // The email should not be changed
    Assert.AreNotEqual(newEmail, updatedAccountFirstTime.Email);

    // Now, after updating the name and everything is working well
    // Returning the old name to the record.
    client.UpdateAccount(id, oldName, oldEmail, null, false, UpdateAccountProperty.Name);

    // Read the record after updating
    Account updatedAccountSecondTime = client.ReadAccount(21);

    Assert.AreEqual(oldName, updatedAccountSecondTime.Name);

Thank you very much for the answers. I've updated my test method to these two methods:

public void UpdateAccount_OneValueExpectedToBeUpdated_Updated()
    GwIntegrationServiceSoapClient client = new GwIntegrationServiceSoapClient();

    int id = 21; // Target account to update.
    Account accountToUpdate = client.ReadAccount(id);

    string oldName = accountToUpdate.Name;
    string oldEmail = accountToUpdate.Email;
    string newName = Guid.NewGuid().ToString();

    // Update the name only because it's passed by propertiesToUpdate parameter (last one).
    client.UpdateAccount(id, newName, null, null, false, UpdateAccountProperty.Name);

    // Read the record after updating from database
    Account updatedAccountFirstTime = client.ReadAccount(id);

    // The name should be changed
    Assert.AreEqual(newName, updatedAccountFirstTime.Name);

public void UpdateAccount_NoValueExpectedToBeUpdated_NotUpdated()
    GwIntegrationServiceSoapClient client = new GwIntegrationServiceSoapClient();

    int id = 21; // Target account to update.
    Account accountToUpdate = client.ReadAccount(id);

    string oldName = accountToUpdate.Name;
    string oldEmail = accountToUpdate.Email;
    string newName = Guid.NewGuid().ToString();
    string newEmail = Guid.NewGuid().ToString() + "";

    // Update the name only, even a value is passed in newEmail 
    // But in the propertiesToUpdate parameter (last one) only Name value is passed.
    client.UpdateAccount(id, newName, newEmail, null, false, UpdateAccountProperty.Name);

    // Read the record after updating from database
    Account updatedAccountFirstTime = client.ReadAccount(id);

    // The email should not be changed
    Assert.AreNotEqual(newEmail, updatedAccountFirstTime.Email);

You should get a copy of The art of unit testing.

Some points to be mentioned:

  • Only one Assert per test.
  • Naming conventions for test method: public void MethodUnderTest_Scenario_Behavior()

How can I mock the interface below?

interface IServiceClientAPI

        ResponseData GetData(string userid,string orderid);

You could mock your interface like following:

public void SomeMethod_SomeScenarioWhichYourAreTesting_ExpectedResult()
    // Arrange
    var mockServiceClientApi = new Mock<IServiceClientAPI>();
    var responseData = new ResponseData(); // Add any necessary initialization to this member
    mockServiceClientApi.Setup(m => m.GetData(It.IsAny<string>(), It.IsAny<string>()).Returns(responseData).Verifiable();

    var someObject = new SomeObject(mockServiceClientApi.Object);

    // Act
    var result = someObject.DoSomething();

    // Assert

In the above code I wrote a test method (which would work with MSTest). Basically you first need to prepare your mocked object and setup any method which you expect your methods to call.

It can be pretty strange to program with mocking tools at the beginning, but once you get a hang of it you will see how valuable it can be. You should first try to understand unit testing and then you will have a better picture about mocking API's. For that I would suggest you have a look at The Art of Unit Testing by Roy Osherove.

That's about it. Regards.

I am beginner of unit testing so I want to ask what kind of function/method we can use as unit testing object.

I want unit test sharepoint code which written on C#.

By the way, I don't ask about unit testing framework. I want to know that what kind of function I can use as unit test object.


   // function that return a value.
   string getTitle()
       // TODO: code logic here
       return "A Title";

   // function that no return a value
   void doAction()
       // TODO: code logic here

=> which one of them can use as unit testing object.

Your question is really vague.

If you're asking about unit testing techniques, get a book. Perhaps this or this.

If you're wanting to test code that calls SharePoint objects, you have to talk about tools. You have to fake these out using either Typemock Isolator or Moles. The SharePoint object model is full of concrete, non-inheritable objects.

I'm a new guy to unit testing in .NET and I want to start with NUnit. I'm using ASP.NET MVC 4 for creating my project. Where can I start to learning NUnit? Can you suggest me some tutorials please?

NOTE: I'm NOT new in ASP.NET and ASP.NET MVC and C#

NOTE: I have some experiences with unit testing in RoR.

You can learn NUnit using Osherove's tutorial and book. Or something called unit testing kata.

Read Art Of Unit Testing by Roy. Good read.

Link to kata testing: Unit Testing Kata

I'm not familiar with mocking. I'd like test if my method GetById return me an object User with an Id. Below the code, I'd like test if the GetById(10) return me an User with id = 10.

I set the moq (I hope it's correct) but how execute the moq ?


public void MyMoq()
    var userMock = new Mock<IUsers>();
    userMock.Setup(x => x.GetById(10)).Returns(new User());

    //After ?
    new Users().GetById(10);

public interface IUsers
    IUser GetById();

public IUser GetById(int id)
    using (var context = ....)
        //code here

        //return user here

Alright, as I said in comments, it's not clear for me what code you're trying to test. I see two options here. 1) The Users class implements IUsers interface and your intention is to test implementation of GetById(int) method. In such case you do NOT need to mock the 'Users#GetById(id)' method, you just need to call it and check the result. The code should look similar to:

interface IUser
    int Id { get; }
class User : IUser
    public int Id { get;set; }

interface IUsers
    IUser GetById(int id);
class Users : IUser
    public IUser GetById(int id)
        // TODO: make call db call
        // TODO: parse the result
        // TODO: and return new User instance with all the data from db
        return new User{ Id = id };

public void MyMoq()
    // TODO: prepare/mock database. That's whole another story.

    var users = new Users();

    // act
    var user = users.GetById(10);

    // assert
    Assert.AreEqual(10, user.Id);

2) Your Users#GetById(int) method is supposed to call the IUsers#GetById(int) and return the result. In such case you need to create mock of IUsers(as you've shown in question) and pass it to Users. The code should be(sorry for possible duplication):

interface IUser
    int Id { get; }
class User : IUser
    public int Id { get;set; }

interface IUsers
    IUser GetById(int id);
class Users : IUser
    private readonly IUser _users;
    public Users(IUser users)
        _users = users;

    public IUser GetById(int id)
        // next line of code is to be tested in unit test
        return _users.GetById(id);

public void MyMoq()
    var usersMock = new Mock<IUsers>();
    usersMock.Setup(x => x.GetById(10)).Returns(new User());

    var users = new Users(usersMock.Object);

    // act
    var user = users.GetById(10);

    // assert
    Assert.AreEqual(10, user.Id);

p.s. Could be useful to take a look at moq tutorial and The Art of Unit Testing book, Part 2 - Core techniques(page 47) - stubs, mocks, etc.

I'm sorry if this appears elsewhere, it may be that my Google-Fu is failing me.

I'm in the process of reading Roy Osherove's The Art of Unit Testing and am thrilled to be able to start doing some Test-First work on my current project.

Roy's book uses NUnit as the basis for it's training. I find myself in the position of needing to use MSTEst in VS 2008 Pro along with the Silverlight Unit Test Framework to do our testing.

Can anyone point me to a good tutorials and references entries for using both of these tools?



AFAIK, the test class attributes for MSTest are identical to that of NUnit. You should be able to use Osherove's book as a guide without too much impedance mismatch.

I'm trying to understand whats happening here. I'm writing some unit tests for asynch'd remoting code

    // a global variable to all unit tests in the class
    private List<ModuleInfo> _moduleInfo;

    public void MyFunction()
           _moduleInfo = new List<ModuleInfo>();

            netCall.MessageRecieved +=
                    delegate(object sender, MessageTestRecievedEventArgs e)
                       // I get a correct response - array of Modules
                       // then try to add to global variable
                       foreach (EducateMe.Shared.Types.ModuleInfo mIn in arr)


// so after the loop the variable _moduleInfo count = 9 // next Test that runs however the variable is empty - so when it leaves the closure it gets reset somehow - how might I preserve this value between tests?

Update -

This is how the array is defined. There's no [Setup] or [TearDown] being used.

public class MyUnitTest
  private List<ModuleInfo> _moduleInfo;

  // then the function definition


There is a second unit test that is simply an attempt to read the value created by the loop. So MyFunction() test passes fine, but once it exits the closure the variable is gone.


PS. This has come with the VS-created unit test

    private TestContext testContextInstance;

    /// <summary>
    ///Gets or sets the test context which provides
    ///information about and functionality for the current test run.
    public TestContext TestContext
            return testContextInstance;
            testContextInstance = value;

Don't know which Testing Framework you are using but in in NUnit there are methods, that can have the attribute [Setup] and [TearDown]. Maybe one of these functions resets the list?

Nevertheless this is a very bad design for unit tests. By this way you design a coupling between two test. So you can never run the second test without running the first test and how do you ensure in which order tests are run?

So instead write some utility function that fills up _moduleInfo within each test with some stubs that are containing the expected values.

A very good source about how to do testing is the book The Art of Unit Testing: With Examples in .Net.

I've always been told that unit tests are supposed to be implementation independent. This makes perfect sense to me - if the implementation of a function changes, it should still meet its API contract and thus the unit tests shouldn't need to be changed.

However, this seems to conflict with the idea of mocking. If I need to mock external dependencies, this immediately makes my tests dependent on my implementation. If I were to use different dependencies, I'd have to change the mock code in my unit tests. Is it impractical/unreasonable to make all unit tests entirely implementation independent?

I'm not sure if I understand you correctly but I try my best.

Let say you write unit test for class PrepaidPointManager. It has method void Recharge(int points) which recharge users point account. During implementation of this class you decided that it should depends on some ICreditCardProvider (because you want to exchange cash for points) and also depends on IPointRepository because you want to persist new points balance in some storage.

Recharge method make some calculation before using credit card provider and before storing balance.

  1. When you write unit test for this class (which is your concrete implementation) you don't want to drag to your test any specific implementation of CreditCardProvider(maybe because it will require internet connection and is slow). The same story is with PointRepository.

For these dependencies you create stubs/mocks (ICreditCardProvider and IPointRepository) and next inject them to PrepaidPointManager.

public void ShouldCallCreditCardProviderPoints() {
   // arrange
   ICreditCardProvider creditCardProvideMock = mock<ICreditCardProvider>();
   IPointRepository pointRepositoryStub = stub<IPointRepository>();
   PrepaidPointManager sut = new PrepaidPointManager(creditCardProvideMock ,pointRepositoryStub );

   // act

   // asserts/verify
   creditCardProvideMock.Received().Charge(/*...*.) // verify if charge was called

Right now your test is independent from implementation details of dependencies(ICreditCardProvider, IPointRepository). That is how I understand term implementation independent from your question.

Of course if you decide that PrepaidPointManager should have other dependencies then unit test code also need to change.

In well designed system you write code against abstraction and when you really need to change dependencies of some class then this change will affect only small amount of tests.

Main idea behind mocking (from me perspective ) is when you write test case you say something like this:

  • I don't care how credit card provider works
  • I don't care how persistence work

I just want to test if when I recharge points then credit card provider is used.

If you want test implementation of concrete CreditCardProvider then simply create new set of test for this purpose.


Using mock is in fact really practical. If you like you can learn few things from this book Art of unit testing

I've been reading a lot lately about RSpec, Shoulda, Cucumber, Test::Unit, FactoryGirl, Fixtures etc. etc. But I'm still confused as to what kind of testing each of them is used for. The kinds of testing for Model, Controller, View, Helper.

I don't know where to begin. Could someone help give an "ordering" to the way I should start? For example, should I learn Test::Unit, then RSpec then Cucumber?

I'd suggest you to read 'The Art of Unit Testing', by Roy Osherove. I strongly recommend you to read Parts 1 and 4.

Although focused on Unit Testing (duh) there are some well-explained concepts that really helped me to understand better the world of testing. It's not a complicated / boring book, I enjoyed reading it even without any previous testing knowledge. Hope you enjoy it too.


Maybe my question will sound silly to someone, but anyway: why we need to test fake code?

I read this book and I can not understand why we need to test units which we initialize by ourself including returning values and e.t.c. If I use fake object it will always return what I want to (if I use AAA pattern) and if logic of my real code will change and will be wrong, unit test with mock or stub don`t show that. Am I wrong?

Or unit-tests need only to documenting how need to work with classes or libraries?

The point in mocking is not to mock the objects you are going to test but to mock those objects which the object under test depends on, like:

TestRunner -> ObjectUnderTest -> MockedObject1..n

Here you test the behavior of ObjectUnderTest which needs some other objects to work. The latter objects are not subject to the current test, and so are mocked for this test instance.

I have been reading the related topics on the web including this site. But I cannot find one with lots of code to explain the subject in question.

I have been practicing TDD and unit testing for a while. I want to find out what should be and should not be unit tested in terms of class level, method level. For example, should I test everything (what is integration test for)? Within a target method, which lines of code should I unit-test? Are there any good principles, and practices on this area, or good reading materials with lots of code sample to illustrate.

The topic here is concerned with server side language, e.g. C#, Java.


Please note that the books below don't cover what I am looking for (if i am correct)

Pragmatic Unit Testing

Art of Unit Testing

Pragmatic Unit Testing isn't the best in the Pragamatic series and the nunit techiques were pretty lightweight and dated when I read it years ago. BUT it's cheap enough and covers principles and practices.

Art of Unit Testing is also a worthwhile read.


Broadly speaking, unit testing should be white-box testing, in integration testing should be black-box.

That is to say, a unit test should rely on the inner workings of a unit of code, usually a method. As a developer you would inspect the possible paths of execution through the method and create a test case for each one. A unit test should also test the method in isolation. Any collaborators or input and output should be mocked, such that only the method under test is being executed by the unit test.

To find paths of execution you need to think about what possible inputs there will be to a method, and what branches (e.g. if statements and exceptions) there are. For instance

public boolean isYes() {
    return someValue.equals("yes");

This method has no if statements in it, but it has three paths of execution.

  • If someValue is "yes" then the method returns true
  • If someValue is some other string like "Yes", "no", "bananas", or "" it returns false
  • If someValue is null it throws a NullPointerException

In this case, thinking about these paths of execution and writing unit tests to cover those cases helps you to think about what problems there might be with the method.

A test where the path of execution visits several units of code would be an integration test. You would run the test in terms of the overall inputs and outputs. You don't care how it works, just that it works.

Personally I would create unit tests based on my own knowledge of the code base, and for each method individually. I would create integration tests based on specifications and individual acceptance criteria from the requirements.

I need to write a use cases to test the mvc applicatoin. How can I do that?

Writing Effective Use Cases should demistify use cases for you. Also, check out Asp.Net MVC Test Driven Development and The Art of Unit Testing