Brad Wilson

pause.ps1

I needed a "pause" command for some of my PowerShell scripts, so this is what I ended up with. Enjoy.

param(
  [string]$message = "Press any key to continue..."
)

Write-Host -NoNewLine $Message

$Host.UI.RawUI.FlushInputBuffer()
do { $key = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown").Character } while ([int]$key -eq 0)

Write-Host ""

It’s Not TDD, It’s Design By Example

The word “test” in software is a very loaded term. The first time I came across a tester (as in, a person performing the quality assurance role) was in my first professional job. We were never taught about testing at college, as we were all there to learn to be “developers”.

It turns out there are lots of different kinds of testing. In a series of blog posts titled Agile Testing Directions, Brian Marick came up with a 2x2 matrix of test types, and describes the activities which happen in each corner of the matrix. If you haven’t read the blog posts, they can help to provide a vocabulary about the kinds of testing that most software teams undertake.

A lot has changed in the nearly 6 years since Brian wrote those posts. Test Driven Development is arguably the most well known and most popular part of the eXtreme Programming software development process. For several years, I’ve been giving talks and coaching teams on how to do Test Driven Development, and by far the most frustrating part of the process has been overcoming people’s expectations when you use the word “test”. For most developers, “testing” is something that’s done by “testers”, not something that’s done by developers. Even those developers who are savvy enough to be doing unit testing are still practicing an activity whose primary purpose is quality assurance.

What the name Test Driven Development has going against it is that it doesn’t properly express the purpose of TDD; namely, that it is a process designed to help you drive and iterate the design of your implementation at the unit level. The result of the design process is unit tests, but their primary purpose is not one of quality assurance; rather, it is an expression of the intended usage of the component under design. In this way, the “tests” that you are writing become the first client of your component, and come into being just before the component’s code is written. The rhythm in TDD is “write a test, watch it fail; write the production code, watch the test now pass; when prudent, refactor the code to increase clarity and remove duplication”.

The unit tests written by TDD have some quality assurance value as a secondary effect of the test, but that is not their primary goal. Their primary goal is to help you design the code, and to give you a safety net with which to refactor your code. Note that when I use the word refactor, I mean it in the classical sense: to change the internal implementation of a component without changing its externally observable behavior; that is, if you find yourself needing to change a unit test, you are not doing refactoring.

Frustrated by the misunderstanding of the purpose of TDD, my friends and I (Peter, Jim, Brian, Scott, and many others, all agile practitioners and coaches) decided to start calling it Test Driven Design. A small change, but it starts to focus on the fact that the process is about design. Unfortunately, that “test” word baggage is still in there, so our next iteration was then Example Driven Design. This worked well too, but “EDD” and “TDD” were still too close together and confusing.

The final iteration ended up being Design By Example (DbE). Now when I talk about TDD, I always call it Design By Example, and explain why we like this name better than TDD. Where TDD(esign) or EDD failed to get traction, people really seem to resonate to Design By Example.

~ ~ ~

As an aside, you’ll note that most of the unit testing frameworks on .NET have the word “test” in them a lot. NUnit started this with the [Test] attribute, which MbUnit adopted, and MSTest converted into [TestMethod]. When Jim and I set out to design xUnit.net, it originally had a [Test] attribute in it as well, which is how it was when we first talked about it publicly at the first ALT.NET event in Austin. Even before ALT.NET, we’d been lamenting the name [Test] for the attribute exactly because of this baggage with the word “test”. We wanted xUnit.net to be a framework that was first and foremost for TDD (erm, DbE) practitioners.

At the Austin event, we decided to rename [Test] to [Fact]. While some users have complained that this is an arbitrary change, we felt it was right because it removed the focus of the word “test” from the code that you were writing when doing DbE. It also lined up very well with the [Theory] feature we added to xUnit.net Extensions to support David Saff’s data theories. The essential difference is: a [Fact] is an expression of some condition which is invariant, whereas a [Theory] is an expression of a condition which is only necessarily true for the given set of data. As such, [Theory]s are driven with external data; if you provide invalid data, then the theory will potentially produce invalid results.

An example of a [Fact] is the condition which says, “if you have failed to properly initialize this object, when you call this method on it, it will throw InvalidOperationException”. There are no variations on this rule; it is always true. An example of a [Theory], using the classic FizzBuzz interview question, is the condition which says, “if you pass a number which is divisible by 3, but not by 5, the result should be ‘Fizz’.” For this theory, you pass values which meet the initial requirement; if you were to pass 4 or 15, though, the result would be a failure, but that doesn’t mean the theory is bad, it simply means the preconditions for the theory weren’t properly met.

find-to-set-alias.ps1

Inspired by Harry's post, I made an expanded version of find-to-set-alias suitable to putting into a script (.ps1) file, which includes warnings and diagnostic information, with an optional -quiet switch (more useful for your profile to automatically find and alias things, when you expect that they might not be there).

Source: find-to-set-alias.ps1

param(
  $foldersearch = $(throw "foldersearch required"),
  $filename = $(throw "filename required"),
  $alias = $(throw "alias required"),
  [switch]$quiet
)

if ((test-path $foldersearch) -eq $false) {
  if ($quiet -eq $false) { write-warning ("Could not find any paths to match " + $foldersearch) }
  exit
}

# If the user specified a wildcard, turn the foldersearch into an array of matching items
# We don't always want to do this, because specifying a non-wildcard directory gives false positives

if ($foldersearch.contains('*') -or $foldersearch.contains('?')) {
  $foldersearch = Get-ChildItem $foldersearch -ErrorAction SilentlyContinue
}

$files = @($foldersearch | %{ Get-ChildItem $_ -Recurse -Filter $filename -ErrorAction SilentlyContinue })

if ($files -eq $null) {
  if ($quiet -eq $false) {
    write-warning ("Could not find " + $filename + " in searched paths:")
    $foldersearch | %{ write-warning (" " + $_) }
  }
  exit
}

set-alias $alias $files[0].FullName -scope Global

if ($quiet -eq $false) {
  write-host ("Added alias " + $alias + " for " + $files[0].FullName)
  if ($files.count -gt 1) {
    write-warning ("There were " + $files.count + " matches:")
    $files | %{ write-warning (" " + $_.FullName) }
  }
}

The Past, Present, and Future of .NET Unit Testing

If this feels like a repeat, then you might be living in that cool Star Trek: TNG episode where the ship blows up in the teaser! Or, it might be that the show's actually available now. :)

At the ALT.NET conference in Seattle last month, Scott Hanselman said he wanted to use the opportunity of all these people being physically together to do some unique podcasts. On my way off to party after the end of Saturday's talks, I received a phone call asking me to come back so we can do a "quick" podcast with all the .NET unit testing framework people. (Note to Future Brad: Hanselman's "it'll only take 20 minutes" means an hour, at least :) ).

The result was an interesting discussion about the evolution of unit testing on the .NET platform. I was there to represent xUnit.net; Charlie Poole was there to talk about NUnit; Jeff Brown was there to tell us about MbUnit and the Gallio test runner; and Roy Osherove was there discussing unit testing in general and the book he's writing, "The Art of Unit Testing".

Small Decisions Sometimes Cause Big Hacks

When .NET was being designed and introduced, it was notable not only in the ways in which it “borrowed” from Java, but also in the ways in which it parted from it. Some decisions were obviously good (dumping checked exceptions comes to mind) while some were clearly troubling (non-virtual methods by default).

Some, though, seemed insignificant at the time until you come up against them. Today’s example:

When is the stack trace for an exception generated?

In Java, the stack trace is generated when an exception is created, and in .NET it’s generated when the exception is thrown. In practical terms, with 99% of throws looking like this, it hardly matters:

throw new SomeException();

The creation and the throw actually happen on the same line of code. The stack trace is identical in both cases.

However, this seemingly small decision has rippling impact throughout the framework and languages. How many times have you seen this code and cringed?

catch(Exception ex)
{
    DoSomething();
    throw ex;
}

We’ve all seen it. That “throw ex” line destroys the original stack trace and replaces it with your own. The C# language team even had to invent a way to “re-throw an exception without destroying the original stack trace”, which is “throw;” on a line all by itself.

This probably should’ve been the clue that the wrong decision was made.

It’s reasonable to think that there might be a time when you have an exception object, outside of a catch block, and you want to re-throw that exception as though it were never caught. In fact, the framework team themselves came across just such a situation and invented their own hack to handle it, and built it into the Exception class.

When you are talking to a class via remoting, an exception thrown by the remote component is caught by the remote end and serialized back to the transparent proxy. The transparent proxy (which is what the client code is talking to) needs to experience that exception just as though it had been thrown locally. The problem is, we’re not in a catch block; we have a hydrated exception, but need to re-throw it without trashing the stack trace.

There is a private field inside of Exception into which you can stuff a stack trace which says “when I throw you, this is your stack trace; don’t make a new one”. This sample helper method shows you how to do the work:

public static void RethrowWithNoStackTraceLoss(Exception ex)
{
    FieldInfo remoteStackTraceString =
        typeof(Exception).GetField("_remoteStackTraceString",
                                   BindingFlags.Instance | BindingFlags.NonPublic);
    remoteStackTraceString.SetValue(ex, ex.StackTrace);
    throw ex;
}

I first ran across this trick via Peter Provost pointing me to Chris Taylor’s blog post on the subject. I’ve used it several times now (in ObjectBuilder and xUnit.net), and I’m thankful for it every time I run across it.

Since we’re talking about exceptions…

One of my biggest gripes about exceptions relates to reflection. The remoting team obviously went to great lengths to hide the fact that you were talking to a transparent proxy instead of the real object. That’s really the whole reason this hack exists in the first place. You can treat a transparent proxy just like the real thing.

It’s not so easy with Reflection. If you invoke something through reflection, and it throws an exception, the reflection infrastructure catches that exception and wraps it in TargetInvocationException. It’s basically an “I was here!” exception: the thing you actually care about it partially obscured by it. Nobody ever really cares about TargetInvocationException; it’s just a reminder that you’re doing things differently than normal, and you can’t treat some thing like you normally would.

I use this re-throw trick when reflection is an unimportant implementation detail (which it almost always is). For example, when running a test in xUnit.net, the test method is invoked via reflection; the person writing the test shouldn’t ever care about that detail. If every exception that was thrown in a test was reported as a TargetInvocationException, I’m pretty sure people would be telling us it was a bug.

So our implementation of TestCommand.Execute() uses this code instead:

public MethodResult Execute(object testClass)
{
    try
    {
        testMethod.Invoke(testClass, null);
    }
    catch (TargetInvocationException ex)
    {
        ExceptionUtility.RethrowWithNoStackTraceLoss(ex.InnerException);
    }

    return new PassedResult(testMethod, Parameters);
}

We originally spun in a loop at the point where we caught exceptions and turned them into FailedResult, stripping off any TargetInvocationExceptions that were contained. But that made testing for TargetInvocationException difficult in some cases, because you couldn’t differentiate between a TargetInvocationException you didn’t care about from one you did.

As such, everywhere that we use reflection, you’ll find a try/catch like this, eradicating the less-than-useless TargetInvocationException from the exception stack. Every time we have to write it, it makes me wish the reflection team had just done the right thing in the first place.