A book arrived recently on my desk ‘Software Testing with Visual Studio Team System 2008’ by Subashni. S and N Satheesh Kumar. On reading the book it provides a workmanlike coverage of the testing features of Visual Studio 2008 including some of the API options in the testing namespace, but I can’t see what it adds to the subject beyond what a user already has access to in the general introductions on MSDN/Help files.
My major problem with the book can be summed up from the blurb on the back ’testing is neither an easy process nor remotely exciting for developers’, OK maybe true but I would argue this is just because they are not test infected yet. I am not going to go all puritanical here over Test Driven Development, but any developer who feels conformable about having code that is not as testable as possible is not professional in my eyes. As soon as you look on testing as your safety net it starts to impact all your design decisions and your ways of working; it becomes not boring but a stimulating mental challenge as to how to make your system as testable and robust as possible.
This book covers the basic tools and menu options for Visual Studio 2008 testing, but it does not really help to explain why to use various tools; it does not provide a basis for the intent behind the various testing techniques. Knowing the tools exist is not enough. Knowing how to apply technique is the key here, I don’t actually care how a technique is implemented in a given IDE or testing framework; I can lookup that in the vendors manual up when I need it e.g. as a programmer I need to know I could use row based unit testing techniques but I don’t care about the actual format of the MbUnit, or MSTest API, that is for intellisense.
This problem is apparent in the books focus on the automatic unit test generation tools in VS2008, OK the wizard exists, but I would never recommend they are used, it tends to produce fragile tests of little business value. If you want to automatically generate test cases look at Pex, but that is too cutting edge for most projects(and beyond the scope of the book), so better to focus on good simple manually code unit test using a good design model, which this book does not cover - I suggest you check a book like Roy Osheroves ‘Art of Unit Testing’ for this type of material.
For me this book, like so many, is coming from the wrong end of the problem. The tools are important and some are better than others, but far better to drive the knowledge from the technique to the tool as opposed to the other way round. In my option the only case where a book on a tool is that useful is when it provides tips and trick (like Sara Ford’s excellent Visual Studio Tips: 251 Ways to Improve Your Productivity), but this book does not really provide any good tips or trick either.
So if you are looking for a printed bound copy of basically similar contents of the MSDN on your desk then have a look at this book, but you could just read the introductions in MSDN online. However in my option neither place is the place to start if you want to learn how to write good quality tests, go back the basics and learn the theory and technique.