Book Review: Testing ASP.NET Web Applications by Jeff McWherter and Ben Hall

When you think about testing an ASP.NET Web Applications you may be thinking about just a few topics. Maybe you're thinking about manual testing, where a tester goes through some scripts with a series of steps detailing the expected behavior of a web application. Or maybe you're a modern .NET developer, just making the move to the ASP.NET MVC framework, and have Unit Testing as the first topic that comes to mind when you hear the words Testing Web Applications.

Testing ASP.NET Web Applications by Jeff McWherter and Ben HallIf you listen to Jeff McWherter and Ben Hall, the authors of the book Testing ASP.NET Web Applications, you'll discover there's a lot more to testing than those two topics alone.

In their book, they cover a large number of different ways to test and a massive amunt of testing terminology, all grouped under ten chapters in total.

Chapter 1 sets the stage and discusses some general topics and terminology. It gives you definitions for test terminology such as tests, TDD, Pass / Fail, Stubs. Mocks, Fakes, Integration Tests, Functional Tests, Unit Tests, Customer Tests, Load and Stress Tests, Acceptance and Regression Tests and more. It also unravels some testing myths although some of them might be a bit too obvious. The last parts of the chapter look at testing from the perspective of two different roles: Developers and Managers. One obvious missing role here would be the Testers themselves as surely they should have a say in this as well.

In Chapter 2 you learn about Design and Testability, mainly from a Unit Tests and TDD perspective. You learn about the different testing frameworks and tools (nUnit, MbUnit, MS Test, xUnit, Gallio) and the SOLID design principle. You'll get tips and inspiration for creating testable APIs and interfaces and learn about Ioc - Inversion of Control - and Mocks, and some ways (and tools) to implement these concepts in your code. It's an interesting chapter as it helps you think about design in order to support testing, and not about testing in order to test your design. Even if you never run a (unit) test afterward, you can take some valuable ideas away from this chapter.

Chapter 3 (briefly) touches on testing ASP.NET Web forms and then spends the majority on testing ASP.NET MVC applications. It shows you how to work with (and test) Data Access repositories, how to use StructureMap as an IoC container and shows you how to build and unit test an ASP.NET MVC eCommerce application called the Wrox Pizza Shop. Again, an interesting chapter which could give you some compelling ideas, but at times I felt I wanted more. It would have been nice to see a bigger repository model with more entities and I would have liked to see some ways to further decouple your repository and your tests, enabling you to test your data access layer reliably without ending up with testing just your test classes. (I wrote about this in my article: Rebuilding imar.spaanjaars.com in ASP.NET MVC 2 - Part 4 - Repositories, Testability and Inversion of Control).

Chapter 4 deals with integration testing and shows some good, usable stuff to make integration testing in a real world application much easier. For example, you'll see how to create a new database from scratch in your test code by executing SQL scripts using SQL Server Management Objects (SMO) so your tests are always testing against the latest database schema. They make it sound a lot easier than it is in reality, though, and don't really get into how you can get the latest schema other than point you to a diff tool such as Red Gate's excellent SQL Compare. In the real-world, this is much harder, especially when you work in a team and multiple team members make modifications to the database schema. Fortunately, another tool from Red Gate, Version control for databases, or Microsoft's Visual Studio for Database Professionals can make this a bit easier.

Chapter 5 deals with automated user interface testing. A tricky and fragile way of testing, but the authors show some interesting solutions and tools to the problem such as WatIn, Selenium and Visual Studio Web Testing. One topic I wished they had covered as I've been struggling with it for a long time, is automated user interface testing in a continuous integration environment. Since CI is a typical server operation, and UI testing often needs a "Windows desktop", the two don't mix well. Some tips or ideas would have been welcome here. But, regardless of that "omission", this (pretty large) chapter does feature a lot of good and useful content with many practical examples. How you'll be able to use this in practice is probably going to depend on a lot of factors. I experimented a lot with automated UI testing in the past, and never got really satisfied with it. However, that's a shortcoming of the techniques, concepts and tools, and not of this chapter.

Chapter 6 deals with acceptance testing and is probably one of the hardest chapters to follow. It features a Wiki tool called FitNesse Wiki. I am sure it could provide useful services, but I could not make heads or tails of the explanation of it, so I failed to see why I needed this tool in the first place and quickly skipped to the next chapter.

That chapter deals with Manual Testing and shows you many different things that need testing (authentication, network, edge cases, external services, usability, documentation and more). It also touches on topics as cross-browser testing, and testing JavaScript. The part about Manual Testing is a bit brief, and could have benefited from more guidelines and a formalized step-by-step Test Plan. Although the chapter has a simple example of a test plan, the plan lacks room for meta data (who, when, where, which application, URL, browser and what more) and has too few detailed steps to make it useful in the real world.

The chapter on performance testing is of great value. Many of the topics discussed are often not considered by technical designers and developers because of the Works on my Machine Certification Program. In this chapter, you see more about designing an effective performance test environment, and learn what the numerous performance counters that ship with Windows, .NET and other Microsoft products ar used for. The chapter also shows you how to use a number of tools, such as Red Gate's ANTS Profiler for .NET, Fiddler, Firebug, YSlow and the Visual Studio Team Foundation Test Suite.

The second to last chapter deals with accessibility testing. While it touches on a number of important topics such as designing, developing and testing for people with disabilities, I am not sure I am sold on the many screen shots of web sites through the eyes of people with color blindness, diabetic retinopath or macular degeneration. They certainly make a point about the impact of the various diseases, but don't provide much advise on how to develop and test for people with these diseases. The second part of the chapter is a lot more concrete and shows the "usual suspects" of accessibility, such as working with images and alt texts, forms designs, and tables. The chapter ends with an overview of the various international Accessibility standards and with a great overview of a whole bunch of tools and services that can help you test for accessibility, both on-line as well as off-line.

Although the last chapter, chapter 10 - that deals with security, seems to start off a bit boring by simply listing a number of different security risks (Cookie poisoning, session hi-jacking, brute force attacks, rainbow tables, DoS attacks, Man in the Middle Attacks and more), it gets really interesting when the real hacks are described in detail, using freely available tools. A number of security hacks are discussed, of which i've seen (too) many being abused in the real-world and in real web sites. Besides a description of the hack, you also learn more about countermeasures you can take.

After this chapter on security, the book ends quite abruptly. There's no looking back to the previous 10 chapters, summarizing the main points. There's also no looking forward, to your sites and applications in the real world, and no advice on how to move onward from here.

All in all, I think this book is well worth the read. I give it four out of five stars as it covers a lot of different test-related topics in a well-thought out way with a strong focus on ASP.NET web sites and applications. However, the book could have been edited (or should I say tested) a bit more thorough. This would have led to fewer code mistakes (there aren't that many though) and fewer awkward speling and grammar mistakes, and a more text in general.


Where to Next?

Wonder where to go next? You can post a comment on this article.

Doc ID 527
Full URL https://imar.spaanjaars.com/527/book-review-testing-aspnet-web-applications-by-jeff-mcwherter-and-ben-hall
Short cut https://imar.spaanjaars.com/527/
Written by Imar Spaanjaars
Date Posted 05/03/2010 21:20
Listened to when writing Atlas Air by Massive Attack (From the album: Heligoland)

Comments

Talk Back! Comment on Imar.Spaanjaars.Com

I am interested in what you have to say about this article. Feel free to post any comments, remarks or questions you may have about this article. The Talk Back feature is not meant for technical questions that are not directly related to this article. So, a post like "Hey, can you tell me how I can upload files to a MySQL database in PHP?" is likely to be removed. Also spam and unrealistic job offers will be deleted immediately.

When you post a comment, you have to provide your name and the comment. Your e-mail address is optional and you only need to provide it if you want me to contact you. It will not be displayed along with your comment. I got sick and tired of the comment spam I was receiving, so I have protected this page with a simple calculation exercise. This means that if you want to leave a comment, you'll need to complete the calculation before you hit the Post Comment button.

If you want to object to a comment made by another visitor, be sure to contact me and I'll look into it ASAP. Don't forget to mention the page link, or the Doc ID of the document.

(Plain text only; no HTML or code that looks like HTML or XML. In other words, don't use < and >. Also no links allowed.