Here’s an interesting scenario: I have a Linq-to-Entities query that is giving me no results when performing a system test, but when I look in the database, logically there should be results. Better yet, the unit test passes. How can that be?
Historically I've advocated naming test methods after the method under test, in order to help find the tests when you need to modify them. Growing Object-Oriented Software, Guided by Tests has shown me that this is a relic of a code-first mentality rather than good application of test driven development, primarily in the section "Test Names Describe Features" (ch 21). "Test driven" development implies that we do not know the name of the method we're going to test. But we do know the functionality (feature) that we are going after, and that knowledge should be used when writing out a test name. For example:
Assuming that you are already sold on the notion of automated testing, it can be useful to put a little thought into how projects will be setup. There are many approaches to this; my approach is based on experience, the wisdom in xUnit Test Patterns, and standard coding best practices. I will try to keep this language agnostic, though my examples will be in C#.
I wonder how many others didn't think to scroll down further on the Pex download page, and find this link? Visual Studio 2010 Moles - Isolation Framework for .NET. Moles is available for free, while the full Pex environment requires MSDN.
Once again I've learned the hard way that it pays to read the release notes. After installing Pex v0.91.x, suddenly I was having trouble running my tests in a particular solution. It has been driving me nuts - Visual Studio was throwing "object reference not set to an instance of an object" errors every time I tried to run tests, and the Test View was refusing to load any test names.
Finally, I noticed that I had a few tests that were still instrumented with HostType "pex" instead of "moles". I changed these around, and still got the error. Closed Visual Studio, restarted, and voìla, the tests can run, and Test View is populated again.
A few weeks ago I stumbled upon a tool called Pex from the Microsoft Research Labs: "Pex finds interesting input-output values of your methods, which you can save as a small test suite with high code coverage." Not having much time to spend exploring it, I was fortunate to have time to attend a Twin Cities Developers Guild meeting tonight and hear a talk on on how to use the tool, which now has me jump started. First a few highlights of what I learned (without cribbing too much from Jason Bock's presentation), and then sample results from the method in my last post.
Here's a really dumb scenario that will illustrate a point about the usefulness of the "red, green, refactor" approach to testing and coding. Here's the functionality - need to test whether or not a string has a value other than 1. Let's say I write a method before any tests:
you have a method that logs a message using the Microsoft Patterns & Practices Enterprise Library Logging Block, and you would like to write an automated unit test for it in NUnit (or Team System — solution is easily adapted). Logging to a flat file doesn't work; the file is still open when you try to read it to verify that the message has been logged. Logging to the database doesn't work; it seems the log isn't written to the database immediately. And so forth. Is there an in-memory way of reading the logged message?
A few months after I first purchased it, I am still reading xUnit Test Patterns. Been reading a few pages every day - now on page 590 with a few hundred to go!
I have finally arrived at the point where the author describes the pattern Test Specific Subclass (TSS). This is a pattern we have used extensively in our testing at the office, so that we can access protected methods in our classes. However, we stumbled upon it on our own, well before reading anyone else's suggestions on how to apply it. That's the nature of patterns for you.
Lately I've been working with my team to understand and utilize good automated unit testing strategies with NUnit. A code release I was inspecting revealed a couple of good points that seem worth expanding on: the importance of testing each layer, and the need to pay attention to code coverage. This is a rather facile treatment; for more in-depth reasoning and details, I recommend xUnit Test Patterns.
