It's the last part of the series, and I just thought I would wrap things up by talking about unit testing the aspect. I wrote a whole chapter in my book AOP in .NET on unit-testing of aspects. I also was honored to do a live webinar with Gael Fraiteur on unit testing with PostSharp, in which he has a different view on aspect unit testing, so I recommend you check that out too.

I'm not straying too much from the book in this example, so if you're familiar with that chapter, there's not much new for you here.

My plan is to not test the PostSharp aspect directly, but instead have the aspect delegate just about all the functionality to a plain old C# class that's easier to test. The old adage of solving a problem by adding another layer of indirection applies. Doing it this way makes my aspect easier to test, further decouples my application from a specific framework, but does require some more work, so it's not like it's a magic cost-free approach to testing either.

Here is the aspect, all tightly coupled to PostSharp:

And here is my refactored code, which you'll notice results in a higher number of classes, but it is ready to unit test. You may also notice that some of the logic is a bit different than the above aspect. This is because I found some issues and bugs while I was writing unit tests. So, hooray for unit tests! Also notice the "On" static field. I touch on this in the book, but this flag is merely there so that I can unit test the actual services while isolating them from the aspect. Since PostSharp uses a compile-time weaver, this is necessary. If you are using a runtime AOP weaver like Castle DynamicProxy, that's not necessary.

I'll even show you some of my unit tests, which I've written in mspec and JustMock Lite with the help of Sticking Place for testing the SqlException stuff.

Notice that I moved the Exceptionless-specific code behind an interface (IExceptionLogger) as well, to further decouple, improve testability, and also because Exceptionless is just the sort of thing that might actually be swapped out somewhere down the line. I've left out the details of that implementation because it's quite trivial.

So now you are caught up to today: this is the aspect I'm actually using and deploying to a staging site for my cofounder and our designer to use and test. And so far I must say that it's working quite well, but things could always change when it actually hits real customers, of course.

I like using mspec to write tests. Here are a couple of tips for getting the most out of mspec with ReSharper.

Tip 1: ReSharper can run mspec tests!

If you use NuGet to install mspec, then look in your /packages/Machine.Specifications.x.y.z/tools folder. You'll see a batch file like InstallResharperRunner.8.2.bat. This will install the mspec ReSharper test running plugin for you. Then those friendly little green test runner dots will show up in Visual Studio.

Tip 2: Use a ReSharper live template to write mspec tests faster

Mspec uses perfectly valid C#, but it's a bit unusual looking and sometimes hard to type all the correct symbols, especially when you are in a hurry. So I created a live template in ReSharper to automatically create the mspec skeleton for me. In Visual Studio, go to Resharper -> Templates Explorer -> C#. Click the New Template icon. I gave mine a shortcut of "mspec" and all I put in it is:

If you've not used ReSharper live templates before, then you're missing out. Just type the shortcut name and hit the tab key and voila.

(Off-topic side note: This is not a paid advertisement, but since I've created a couple of them now, I thought I'd mention that animated GIFs like above are super easy to create with Camtasia Studio from TechSmith, which is also a great tool in general for creating screencasts as well).

May 13th is .NET Day at manning.com. My book (AOP in .NET) is featured as part of this Deal of the Day.

The offer also applies to:

• C# in Depth, Third Edition by Jon Skeet
• Fast ASP.NET Websites by Dean Alan Hume
• Windows Store App Development by Pete Brown
• HTML5 for .NET Developers by Jim Jackson and Ian Gilman
• Metaprogramming in .NET by Kevin Hazzard and Jason Bock
• Dependency Injection in .NET by Mark Seemann
• ASP.NET 4.0 in Practice by Daniele Bochicchio, Stefano Mostarda, and Marco De Sanctis
• F# Deep Dives by Tomas Petricek and Phillip Trelford
• And C++ Concurrency in Action by Anthony Williams

The deal will stay active for about 48 hours. (They let it run a little longer than a day to account for time zones). So get yourself some books!

Use promo code dotd051314au.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

This is a special edition of Weekly Concerns, in that I'm attempting to cover the recent dust up over TDD that was triggered by DHH and responded to by several notable developer pundits. Note that I respect all of the developers in this conversation and I believe they are all making important points, but the way they communicate can be somewhat... abrasive... so make sure your jimmies are secure before you start reading.

• April 22: David Heinemeir Hansson's opening keynote at railsconf which lays the groundwork for...
• April 23: TDD is dead. Long live testing. by David Heinemeir Hansson.
• April 25: Monogamous TDD by Uncle Bob Martin.
• April 29: RIP TDD by Kent Beck
• April 29: Test-induced design damage by David Heinemeir Hansson.
• April 30: TDD, Straw Men, and Rhetoric by Gary Bernhardt. First DAS blog post in years.
• April 30: When TDD doesn't work by Uncle Bob Martin.
• April 30: Slow database test fallacy by David Heinemeir Hansson.
• May 1: Test Induced Design Damage? by Uncle Bob Martin.
• May 1: The TDD Divide: Everyone is Right by Cory House.
• May 2: Professionalism and TDD by Uncle Bob Martin.
• May 3: A remix of Professionalism and TDD by Gregory Brown.
• May 9: Is TDD dead? Part 1 panel discussion on Google Hangouts with David Heinemeir Hansson, Kent Beck, and Martin Fowler.

Lots of others have weighed in, of course, in blog posts and on Twitter. This type of discussion has been going on since Kent Beck wrote his TDD book; I believe it will continue long into the future. So I guess it's probably a good time to reread Jim Holmes book "Best Practices in Software Engineering and Testing", which is no longer available, but I will reprint in its entirety here (completely from memory, so forgive me if the phrasing isn't quite right):

"Use your brain."

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

Having been almost a month gone from Zimbra (aka Telligent), I'm starting to remember and notice some things that I've previously taken for granted.

One of the axioms that was drilled into me in my early days at Telligent was "no ticket, no work". Which is to say, if it's not work that's been defined and entered into the backlog and approved for work and ready to be tracked, then don't do it. There are several benefits to this approach. One is that it tends to address gold-plating and adhoc features (since I have to take the time to think about something and communicate it to the team).

But one of the things about this approach that I definitely took for granted was how this helps with tracking. For every commit I did to source control, I had to put the ticket number in the commit message. The tracking system we were using just happened to have the ability to integrate with source control, which was nice. But even if it didn't, as long as I know the ticket number, I could very easily search the commit logs and see what code changes were made for the ticket in question. This made code reviews, retrospectives, conflicts, documentation, bug fixes, etc so much easier.

It doesn't cost you but a few seconds to put the ticket number in your commit message, and a few more seconds to put in a decent commit description while you're at it.