# BehaveN

I’ve been using a Cucumber-inspired BDD framework for .NET called BehaveN at work for the past year. Today, I just released the next major version.

There’s a little documentation on the wiki, including a tutorial, but there’s a lot left that I haven’t documented yet. I’ll be getting more and more documentation up as time goes on.

It’s been pretty positively received by our product owners, QA, and most of the developers who’ve been exposed to it. It’s being used by a few outside my company, but I haven’t made any effort on “advertising” it. If anybody’s interested in giving it a try, let me know and I’ll try to fill in any of the blanks you might have.

# Autotest for Python

I recently went looking for an autotest equivalent for Python.

This question on StackOverflow pointed me to autonose. It wasn’t that easy to install using easy_install since one of its dependencies (snakefood) failed to install so I had to do that manually.

Unfortunately, autonose has a few issues, especially when running on Windows. Since it doesn’t appear to be updated anymore, I went searching for an alternative and found pyautotest, part of the Modipyd project. It doesn’t use nose, but that’s OK, because I wasn’t using anything that required it.

I had to install Modipyd by downloading its source from this GitHub repository and running python setup.py install.

Pyautotest is exactly what I was looking for–simple and works right out of the box without a nest of dependencies. The only part I was missing was support for Growl for Windows.

Ian Lewis and his co-workers released some custom test runners that can be used via pyautotest. The Growl version uses the growlnotify tool, but that didn’t work with the version of growlnotify.exe that works on Windows.

I started modifying their runner to work with growlnotify.exe, but it really bothered me how they copied and pasted the entire contents of the unittest.TextTestRunner.run method into their derived class so I threw together my own version which doesn’t contain such a flagrant disregard for object-oriented principles. You can clone/fork it here.

For the icons, I used Jamie Hill’s pass/fail smilies which I found here.

I hope this helps others trying to do TDD with Python. I absolutely love saving in Vim and seeing a green smiley face immediately appear. =)

# Selecting element content with Vim

When editing an XML file in Vim, I wanted to delete the content of an element so that I could replace it with some completely new text. I thought I could use ct< to change up until the next < character but that didn’t work because the end tag was on a subsequent line.

I learned I could use c/t<CR>, but I use hlsearch and that left me with all of my < characters highlighted. Yuck.

Then I stumbled upon the it motion. A quick cit and all of the content inside the current tag (no matter where the cursor actually is) gets deleted and I’m ready to replace. Perfect!

# One-line lazy initialization

Is this too obscure?

public class MyObject
{
private MyExpensiveObject _myExpensiveObject;

public MyExpensiveObject ExpensiveObject
{
get { return _myExpensiveObject ??
(_myExpensiveObject = new MyExpensiveObject()); }
}
}

# RogueSharp

I just pushed a pet project of mine up to GitHub today. It’s a port of the original game of Rogue from C to C#. It’s not complete–it doesn’t save your progress and let you continue on later, but it is playable.

Now that the actual port is done, I plan on cleaning up the code. Like most software written in C in the 80s, it relies on way too many global variables, uses an abundance of switch statements on object types, and has no abstraction between the game logic and the UI. Since it’s on GitHub, that should leave a nice history of the refactorings I try to apply to it. Of course, before I can try to do any refactoring, I need to get some tests in place. That should be fun considering how much it relies on direct access to the curses library and a random number generator.

The repository is here. Feel free to fork it to help out if you like.

# A Useful Fiddler Bookmarklet

IE 7 and up are hard-coded to bypass the proxy when the host is “localhost”. When Fiddler is running, you can change localhost to “ipv4.fiddler” to trick your browser into talking to the Fiddler proxy as documented here.

Since manually changing the host every time I want to test an ASP.NET or Silverlight application is so tedious, I wrote this little bookmarklet to do that work for me:

javascript:(function(){window.location=window.location.toString().replace('localhost', 'ipv4.fiddler');})()

Paste that (as a single line) into the URL box of a favorite in IE and you’re one click away from tracing the requests between your browser and your local development web server.

I’ve been doing a lot of Silverlight work recently so have found this especially useful to debug the interactions between the client and the server.

I took some time tonight to throw together a build script for producing proper releases of AutoRunner. If you don’t feel like compiling it yourself, you can get a pre-compiled version here.

I used ILMerge to merge the Growl for Windows assemblies into the executable so it’s basically a single file now.

By the way, last night on Twitter, Steve Bohlen pointed me to this port of the original autotest to .NET. I took a look at the code and it was much more complex than I was looking for. It actually builds and runs your tests every time you save which is much more often than I want.

I had AutoRunner turned on all day at work today and was loving how it would catch me breaking the tests when I wasn’t expecting it to. =)

# AutoRunner

I recently came across this awesome code kata performance by Corey Haines here.

Besides enjoying and learning from his actual performance, I was really impressed by his use of a Ruby tool called autotest. (I’m not sure, but it looks like it has become autospec.)

Not being a Ruby developer, I wanted the same thing for .NET. I did some searching, but my Google-fu failed me so I spent an hour hacking together my own.

The result is called AutoRunner (I know–way creative) and its source is available on GitHub.

If you want it, you have to download the source and compile it yourself for now. (UPDATE: You can now download it here!) Run it from your favorite console (PowerShell, right?) without any arguments to see what options it accepts.

AutoRunner is a little more general purpose than autotest/autospec is. Basically, it can run any executable when any file changes.

What I wanted it for was to run nunit-console.exe whenever my current tests assembly was rebuilt. To do that, I just invoke it with the right arguments.

If you have Growl for Windows running, it will send it a notification which is pure eye candy and not necessary to actually get it to run your tests.

It’s not a Visual Studio add-in. It’s just a plain old console application. Using Visual Studio’s External Tools feature, however, it’s almost as good as an add-in. I set up an external tool with the appropriate arguments and it’s good to go for all of my projects.

To set this up for yourself, you’d create a new external tool with its command set to the path where you built AutoRunner.exe and its arguments set to something like the following (I’ve separated the options on their own lines, but you wouldn’t do that in Visual Studio):

--target $(BinDir)\$(TargetName)$(TargetExt) --exe C:\path\to\nunit-console.exe --pass "$(TargetName) FTW!"
--fail "Oh noes! \$(TargetName) is FAIL!"

You can use whatever test runner you like, of course. Please note that you must have a file from your tests project open or selected in Solution Explorer when you activate the tool or your AutoRunner instance will be watching the wrong DLL!

It doesn’t support plug-ins the way autotest does and most of its functionality is hard-coded for now. If anybody finds it useful, let me know and maybe we can work on improving it together.

# SharpTestsEx

I’ve been using Fabio Maulo‘s NUnitEx project to get fluent assertions on a personal project recently and have been loving it.

He then went and moved on to a new project called SharpTestsEx, which he intended to be framework-agnostic, but currently only worked with MSTest which prevented me from being able to use it (since I never saw a compelling reason to switch to MSTest).

Fabio was kind enough to let me make the changes necessary to remove the dependency on MSTest. A also made framework-specific versions of SharpTestsEx for MSTest, NUnit, and xUnit. The framework-specific versions aren’t really necessary, but they make the error messages a tiny bit prettier if you use the right one for the test framework you’re using.

You can read Fabio’s announcement here.

I plan on updating my personal project to using SharpTestsEx next.

I just realized I never posted about that project; I’ll have to get around to that soon. If you’re curious, it’s a behaviour-driven development framework for .NET called BehaveN. I’m using it at my work and we’re loving it.

# Resurrecting Old Posts

Chris Kapilla reminded me in a comment that the World Wide Web is made of links. When I lost all the content in my weblog, I left a bunch of dangling links out there (like those in this Verify JavaScript with JSLint during build using Nant post).

So I went and found an old copy of my Verifying JavaScript with JSLint and Visual Studio post in Google’s cache and added it back (by hand!). I don’t expect I’ll be doing that for all of my old posts, but since somebody found that one interesting, I thought I’d put a little bit of effort into bringing it back.