Unit testing and UI testing in .NET

Question

I am new to unit testing. I want to know to what level do I need to do unit testing. I mainly work on web applications. I am currently working through an MVC book and they showed a couple of unit tests for grid paging, and populating a menu control. Does one have to test business object properties, methods, data layer, stored procedures, etc? I don't want to look paranoid and test everything. If it is best practices then I will do it.

For example, if a first name property is supposed to be 50 characters long, and may contain only alpha characters then do I need to test both?

I am also using the Yahoo User Interface library, do I need to test this as well?

What UI unit testing tools are available? I have heard that there are frameworks that allow you to mock a whole even if it is not there and then you can test the page this way? What frameworks for UI testing are available?

I would like to hear as much opinions as possible? Any suggested books for beginners with many samples would be appreciated.

Thanks

Answer 1

Don't test properties, methods, data etc. Instead, describe the behaviour you're looking for and provide some examples which show how you can use the class.

You'll find that most of the behaviour in your codebase is valuable, so you can get high levels of coverage this way without looking paranoid. (If it isn't valuable, delete it!)

For instance, you could have a validator which read:

[Test]
public void ShouldOnlyValidateAlphaNamesLessThan50Chars() {

    var validator = new Validator();

    Assert.IsTrue(validator.validates("An Alpha Name"));

    Assert.IsFalse(validator.validates(
        "A Really Really Long Name that's 51 characters xx"));
    Assert.IsFalse(validator.validates("A name with 1234 numbers"));
}

This is enough to show the kind of behaviour that the validator should have.

I would put enough examples in each test method to show the valuable nature of the code. Experiment with it. Some people prefer "One assertion per test" but it doesn't have to be that way if it works better for you differently.

With respect to 3rd party libraries, I'd think about what they're doing for you that's valuable, then wrap them up in another class which you can mock out. Moq is my favourite .NET mocking framework of choice.

For UI testing, especially for web pages, I'd look at Selenium.NET. However, this is used for testing the entire system - we don't normally unit-test UI elements. This is partly because it's hard and expensive, and partly because actually looking at them, using them and playing with them in context is the only way to check that they're behaving properly.

QUnit is the framework I've seen used for Javascript testing, if you're using that in your pages and want to test that too.

Answer 2

Yes, I would test "everything", however, user interface testing is generally complicated and brittle to test, in the interests of pragmatism, I'd keep your UI code as small as possible, and just Be Careful.

Definetly test all "business code".

Speaking from experience, it was difficult to learn how to unit test effectively, but once I began applying dependency injection patterns more often, it became much easier to test.

Try to test only ONE thing at a time - testing a "system" tends to make the system test complicated and brittle.

When I say "brittle", I mean "A simple change in one part of the system just meant that you have to rewrite half your tests". What you want is to have a change impact only a few of the tests that actually test that code.

Answer 3

As well as agreeing with the other answers here I'll also add a pragmatic point that I've found extremely useful.

When learning to write tests and getting used to the testing paradigm it's often hard to know where to begin and what to test first. Testing everything is very much an ideal that can be acheived however there's a pragmatic aspect to how much you can do right away.

Given that you're working on a web project, one thing I've found very helpful is to start testing code that requires a lot of effort to test in the usual way.

An example of this that I have from a recent project is integrating some blogging mechanisms into our site based on a feed from blogger. In order to test my code I would have to build the blog project, then build the web project that references the blog project (which takes about 3 minutes in Visual Studio), then navigate to the page in question (waiting for the code to go through it's sequence of events upon first run after build) and then go about testing the actual thing I'm interested in.

To make this process a lot easier you can begin writing tests for these kinds of scenarios. I'm a fan of TDD and testing in general and I've found that this kind of approach really gives the developer a more grounded idea of how and why testing can be useful. You really get to see a benefit right away by reducing the amount of time and steps you have in order to test some functionality. Managers can also highly appreciate this. (It's a bit less fluffy than some of the more idealistic concepts and banter surrounding testing).

This approach also gets you into the fun aspect of writing tests. As with anything, if you start off by finding out how you can enjoy the process, you're more likely to continue doing it.

I've worked with many an evangelist who snubbed out any fun or interest a new developer might have found through testing and made the whole process very religious. Make testing fun and you're more likely to want to test more of your code.

Answer 4

Testing everything is not realistic for a large application. Even for small applications, you are going to spend a lot of time to write unit tests for everything. Only a small portion of your system is actually worth unit testing, as most code is performing trivial logic and testing it is not truly beneficial. If you are being paid by the hour and have unlimited time, I would say go ahead and test everything. But if you are working on a timeline, then you are going to have to be smart about what you test.