ALM is the enterprise software development holy grail that IBM sought for years and invested in with the Rational tools. And although there is a tremendous value in prescriptive guidance in enterprise development models, there is a natural tension between the ALM crowd and Development as a Craft advocates. ALM, after all, is all about quantifying, measuring, predicting, planning, and economies of scale. Ironically, the kind of transparency and predictability called for by the minimalist Agile community is the same goal of ALM tooling offered by Big Blue and now by the new blue in Redmond.

How are Microsoft products staged to lay across the ALM model? The story today is mixed.

Your familiarity with these products may lead you to the same conclusion that many have already reached. The products in the stack currently fail to integrate cleanly and many provide only a starting taste of the functionality needed to realize the ALM vision. The story is obviously a little muddy today. But what’s next?

Team System Rosario promises much improvement in the areas of tracking, design, quality assurance, and development. Significant bridges are also being started toward improving the release management story.

That won’t do it all, of course. There are other pieces needed in the stack that will need to be freshened up including operational support tools. Microsoft is in hot pursuit of filling this gap with a host of products under the System Center umbrella of products. An actual helpdesk management system to displace the TechExcels and Remedys of the world is essential here.

The point is, MS has its sights set on a complete ALM story and are focusing on the midsize market, as Microsoft is so good at doing.

The Good

A focus on ALM in the Microsoft stack will have a tremendous impact on software development and delivery as we know it. Interoperable components in the pipeline will help bridge those gaps in midsize organizations that are typically only filled in large enterprises. Transparency will be ubiquitous.

Given the open nature of products being developed at MS these days, I have high hopes that these systems will truly be pluggable, so that if you want to bridge TFS to Remedy (for example) doing so is not rocket surgery. Web services are great, aren’t they?

Concerns

There is a fine line between managing for predictability and ‘command and control’. Tools like those in this stack are like guns. They can be used for good, but misuse is more common than not.

Tooling like this gives every non-tool Agilist out there genuine pause, and with good reason. The history of stewardship in complex models like this is less than stellar. That is to say, this tooling can provide huge value, and the basis for crushing souls. Let’s be careful how we wield them.

Depending on who you ask you will likely get one of two answers.  If you are talking with a data guy, he will say to start with the database.  If you are dealing with a visual guy, he will say to start with the UI.  Historically, I did a conglomeration of those two ideas, creating both the UI and the database at the same time, letting the two drive each other.  But I’m weird, I’m a visual/data guy.

Lately though, I’ve started to thing about a third approach.  Starting in the middle.  No UI, no database, just the data classes.  This approach has been spurred on buy a couple of things.  Namely, test driven development (TDD), design patterns, and domain driven design.

TDD really is the glue that allows all of this to happen.  I can start in the middle because I can run the code in the middle any time I want.  I just have to write a test.  No having to wade through multiple layers of UI to test out some small chunk ok UI is a great productivity gain for me.

Next is design patterns.  This is what gives you a reference for how to approach your code.  That said, this isn’t about making everything absolutely perfect from the get go, but it is nice to know where you are going to made your comprises early on.

But all of that does not explain where I begin.  That is where Domain Driven Design (DDD) kicks in.  For those not familiar with the concept, you can read up on wikipedia, buy The Book, or buy one of the various other references.   One of the concepts in DDD (I’m still reading the book) is setting up something called a ubiquitous language.

The ubiquitous language is actually trying to solve a problem that I have seen happen on many projects I’ve been apart of (but not always my fault).  At some point there is a linguistic difference between the nouns that the customer uses and the nouns that the programmers use.  By focusing on the language first, you are attempting to head that off at the pass.

These nouns consist of your domain classes and your tables and columns, they move everywhere…but not always consistently.  Consistency does matter.  Inconsistency is what leads to rather confusing conversations with people and everyone scratching their heads about “what just happened”.  So, this is the middle that I start with.

But before you start…

One of the other guys in the group was an actual data guy.  The systems he has written worked with more data than yours does.  Trust me on that.  Historically, his biggest consideration was data input speed.  I don’t think I would start in the middle if that was my biggest concern.  In that case you do start with the database, you tune for speed.  You also don’t use as many domain classes, and you tend to throw away your ORM solution and just hit the database layer directly via Ado.Net.

But lets face it, that doesn’t happen very often.  Most business applications aren’t going to touch what the architecture can take.  It is amazing how many horribly written applications with very inefficient code run just fine.  Most of my speed issues could be solved by indexing tables and changing generic lists to generic dictionaries (more on that later).  Architect your applications for how they are going to be used.  Most of my web applications have a max usage of 100 simultaneous users.  If the data access is slightly slower I’ll take that hit for programmer efficiency.  If you are designing Amazon.com, you code for through-put.

OK, someone is going to disagree with this…I can already feel it.  Please take a moment to register your displeasure in the comments.  I would love to hear it.

We know that the modeling tools in Team System 2008 are, well… there’s room for improvement. How valuable is a Logical Data Center Design Model when we can’t derive it from a reverse engineering action? There has also been much frustration with the lack of standard UML support in Visual Studio. Guess what?

Rosario proposes that we promote modeling to a first class citizen of the complete Application Lifecycle Management model. Here’s my major takeaway: The way modeling is being supported enables visual exploration of your code base in a way that is seamless with the development process. This can honestly change the fundamental code development experience.

Also, I can plan on sun setting all my organizations Sparx licenses. Cool.

• UML 2.1 at the logical layer
• DSLs at the physical layer
• Generate models from existing assets. This is being discussed as “Architectural Discovery” which is a hilarious term in itself.
• The April CTP has the following
• UML Class Diagram
• UML Use Cases Diagram
• UML Sequence Diagram
• UML Component Diagram
• UML Activity Diagram
• Architecture Explorer
• There is a unifying model underlying all of this, the diagrams are simply views upon that model.
• Newer versions will have some of the features we got to see today. These will come in another CTP later this year.
• Layer Diagram
• Seriously cool, this allows to separate concerns of our tiers in a system.
• I can bind my namespaces to logical layers of my application
• Also has some seriously cool visualization tools for looking through your code.
• Using these views, we can see our cohesion and inheritance in physical form.
• How about namespace visualization using a graph model? Dang, this is cool.
• How about a dependency visualization? NDepend better look out because this one isn’t half bad.
• AND, all views enable us to click right through to our source code. Neato.
• XMI support (seriously, wow). This means we can export models from other applications like Sparx EA, Altova, and Rational and bring them right into Visual Studio. Oh, and it will pull Visio models as well.
• Round tripping of component models to code
• Peter actually built some sequence diagrams and I gotta say that this UX is going to be MUCH better than Enterprise Architect, which will soon loose it’s Market Share. Even use cases look neater.
• Sequence diagrams can be round tripped with classes and even methods. This means we can examine the complexity of our code at a usable level, and do it visually.

What if you could prescribe separation of tiers and limit leaky abstractions?

Nuggets

“Any system should be possible to represent on a white broad in no more than 13 boxes.”

“Using model is simply a way of managing complexity.”

“There will be a model store capability that means we don’t need to keep our models in the same solutions with our code.” But you can

Because the models are all built on DSLs, there is someone out there who has automated the process of building test cases from activity diagrams. That is hotter than a 2 dollar pistol.

We can attach other files like Word files to your model itself.

What if we could could light up the models in the debugger to see highlighting of current activity in a sequence diagram? Neato.

They are trying to figure out how to include support for generating design patterns like found in EA and Rational. This is fun because you can generate domain specific code with a fundamental implementation in a known design pattern like Forward Controller or something.

I need a bigger monitor. Seriously, boss. I need a bigger monitor.

So this is, in brief, the pattern that I use to communicate changes via version numbers.  It’s one way to handle the problem, but of course not the only way.  Also, this is for the projects that aren’t [yet] under automated build like CruiseControl; for those I use a different pattern, which will be a separate post..

Building Versions

The .NET assembly version is broken down into {Major}.{Minor}.{Revision}.{Build} (although there is some disagreement about this, and some inconsistent documentation… but lets ignore that for now.  You like your definition better?  Great, use that one instead.) 

Major: Obviously, big sweeping changes to the project: changing .NET framework versions, changing major supporting libraries, or for that matter just rewriting the thing.  There is absolutely no expectation of interface compatibility between major versions, and those upgrading should expect breaking changes and have to do some work on their part to take advantage of the new version.

Minor: Slightly less sweeping changes, but still pretty big: major architectural activity, inclusion of big feature sets, etc.  There is no expectation of interface compatibility and there will likely be breaking changes.  Upgrading minor versions should expect some changes. 

There is a lot of room for interpretation between what’s Major and Minor, personally I try to reserve Major for the biggest of changes, and do minor revisions more often.  But this is left up to your discretion.

Revision: A change to a project that alters its public interface, but doesn’t necessarily represent adding big features.  This could be adding smaller functionality or more commonly, bugfixes and refactoring.  Revisions might maintain interface compatibility.  Upgrading revisions should be straightforward.

Build: A change that doesn’t alter the public interface, or is otherwise “very small.”  We need to re-release the project, and don’t want someone to confuse this release with the previous one.  Builds should keep interface compatibility.  Upgrading the build shouldn’t require changes to the user’s code.  Often CruiseControl.NET gets put in charge of this number, but that’s a topic for another day.

None of this is absolute – there is a ton of space between each of these categories, and this sort of thing is usually left up to the developer’s own discretion.  I think it’s important for your organization, or at least for a developer, to have a method to your version naming madness.  You like your method better?  Great!  Post it in the comments for all of us to learn from.

Many of the technologies we work with don’t easily lend themselves to unit testing: web pages, stored procedures, 3rd party controls.  You’ll probably have to learn some new technologies that make testing practical, which also takes time and energy.  You might have to write test barriers between the "untestable" part, and the logic; moving as much logic out of the hard to reach area and into easily tested code as possible.  Which at a minimum represents more classes, more complexity, more typing…

Writing testable code is hard, and requires a shift in how you write code.  This shift won’t come overnight.  At first you will write "sort of" testable code, hopefully following some ideas laid out by other codebases (Various parts of Castle, ASP.NET MVC, and Rhino-Commons and other examples by Oren Eini are some good places to start).  You will end up making mistakes, and a few months later you’ll look back at this code and wish you had done things differently.  If you’re not having that experience with your code, then how have you improved as a developer?  If you look at last year’s code and think that you’d change absolutely nothing, doesn’t that at least imply you haven’t improved your skills?

"But, we don’t have time to write unit tests."  Does that mean that you have time to debug your application by stepping through hundreds of lines of code?  Do you have time to litter your code with printf()s hoping to track down where a variable gets set to null?  Maybe we’re just too used to the Edit-Build-Debug Cycle taking minutes for each iteration, waiting for ASP.NET to finish compiling its pages so we can navigate to where the problem is, enter what we think the bad data is, click a button, and then start hitting breakpoints… lather, rinse, repeat, for hours on end.

So when the project gets to the end of the timeline and budget, and the result is buggy, and we’re breaking more things with each deployment because of regression issues, and the client starts saying things like "this project is a total failure," and the project manager is demanding that everyone start putting in all-nighters to deal with the bug list … is that better than an alternative of spending a little bit more time up front on writing easily-tested code? 

So, how about we strike a pragmatic agreement – identify a difficult part of an application you’re working on, and figure out how to write unit tests for it.  I’m not even talking about "test first" or "100% test coverage," just write something to make it easier to confirm that the behavior of this code is correct.  At least identify the parts of your code that stand in the way of tests – its almost always database or web-dependencies, and is an indicator of further problems, but we’re taking baby steps here.  See how that goes, and see what you can learn from it.

I await your flames in the comments…

From what I gathered from David Laribee’s article, I like this. I REALLY like this.

By changing namespace, class, and method names, the behavior of each spec (test) is clearly revealed. In a larger suite of tests, if there are failures, I can more easily see what is failing and what trends, if any, are resulting in my failures. Before, I would name my test method names to describe a behavior, "Some concept should do this when given that." Getting the namespace and class name involved provides a more legible test result.

While reviewing a test case for a peer, I took this approach and arrived at the following scenario. I am changing the names of the methods to hide details. The original test method was "FilterToEndPointTestReport." Making this more readable, using my previous approach, we arrived at "FilterShouldUpdateStatusOnReportWhenDefaultFilterValueIsChanged." Great, that is better, but…

Applying the approach described in David’s post, I now have this.

   1: namespace Specs_for_Filters

   2: {

   3:   public class When_default_filter_value_is_changed : FilterTestFixture

   4:   {

   5:     [Test]

   6:     public void Endpoint_should_be_updated_on_report {}

   7:     

   8:     [Test]

   9:     public void Endpoint_should_be_updated_on_grid {}

  10:     

  11:     [Test]

  12:     public void Endpoint_should_be_updated_on_chart {}

  13:   }

  14:   

  15:   public abstract class FilterTestFixture

  16:   {

  17:     // provide common functionality that will be used 

  18:     // among behavior-driven filter test classes.

  19:   }

  20: }

When my tests run, their resulting output is more legible. This approach helps me to think about my tests in terms of behavior rather than implementation. In my opinion, my test cases are now more abstract and more succinct.

I thought Martin Fowler answered the question very well:

“Anything that causes a state change to my world, my domain model… I capture in an object, you can think of it as a command object, I like to think of it as an event object. That object carries with it all the information about the kind of state change it might be. Then I have some way of processing it against my domain model to actually perform the change, but I still store and persist that event object as part of the record of what I’ve done.” DDDD video, 49:00ish

He are a couple of great articles from Martin’s site which elaborate on his statement, if you are interested in making the transition from request/response to messaging I recommend giving them both a thorough read. I am currently in the process of making the transition myself and I found them very helpful.

Fowler – Event Sourcing

Fowler – Event Collaboration

Also from the session came a great list of other reading materials, so bone up!

Pattern Oriented Software Architecture Books 1-4

Enterprise Integration Patterns 

Domain Driven Design 

Domain Driven Design Quickly (Free 100 page compressed version in PDF provided by InfoQ)

Power of Events

Distributed Event Based Systems

Event Based Programming

Software Architecture in Practice (weighing ‘ilities’)

SEI – Quality Attributes (PDF)

Thanks to all the attendees including Evan Hoff, Udi Dahan and Greg Young for helping compile the great list of books you see above. (as well as their contributions to the conversation in general)

The open spaces format makes it easy for whoever is there, to talk about whatever they want. DDDD, or distributed message base systems in general, was exactly what I wanted to talk about. This was my first open spaces conference, so I was a little nervous to be convening in front of highly respected peers. Luckily with all the tremendous talent in the room, being the convener for DDDD was about as complicated as finding a Starbucks in Seattle. I also learned the golden rule of open spaces, which is – if all else fails… turn it into a fishbowl.

Part of the responsibility of the convener is to provide a take away of what was talked about. Unfortunately given the magnitude of the topic, and my hectic schedule, I am sitting here 1 week later looking at 4 pages of thoughts and no real way to comprise what’s in my head. So my solution is to break it up into a series of posts just to get something out there.

So let’s start with the video. The conversation is very dense, and is packed full of great info. Some of what is said is hard to follow without context, so I challenge you, if you are interested in the topic to listen to it several times. Even after being in the room, the 3^rd time I watched the video I was still learning more and more.

I think you have to write DTO’s for any sort of long term Enterprise ‘system of systems’ solution. I fought this for some time, but since moving to an Assembler/DTO I much enjoy the freedom of being able to easily tweak my DTO “snapshot” of the aggregate root I am working with. Maintaining them is very little overhead.

I tend to think of the DTO as a message, a value object. This is necessary because once an entity leaves the boundary it can no longer function within its original meaning. Its methods may be intended to only run within a given context, which is not the same once on another tier. (Things like lazy loading are a good example) Once the DTO/Message arrives to the caller, it very well may (and probably should) be translated/assembled into another model which can represent its new semantics.

Some other advantages of DTO w/ Assembler or Builder:
-Can explicitly control the depth of the graph/tree you are serializing.
-Can flatten out the data where needed
-Can return significantly less data (maybe you only need 3 fields instead of 15)
-Not tightly coupled between remote boundaries (this could be a mess when working with a large team)
-Interoperable

I wrote a post a while back showing a way to ‘templatize‘ the process. My current implementations are much different with LINQ now, but maybe it could stimulate some ideas for whomever.

The next thing I would like to do is remove the assembler altogether. By flagging fields with attributes or using config to specify a mapping, I could then feed dynamic methods and run a translation/builder strategy.

I know there are concerns about writing and maintaining assembler and DTO, but to me this is the least of the worry, a more challenging scenario would be the UnitOfWork (How to you intended to track remote state, concurrency etc) How about versioning? performance? scala.. well ilities in general?

These kinds of problems lead one from Request/Response, Patterns of Enterprise Architecture & DDD to a Pub/Sub Message Bus – Enterprise Integration Patterns & DDDD.

And to think all you want to do is send some frickin entities to a remote client 

After seeing too many duplications across methods in one or more classes, I decided to investigate a way to remove these. I am always looking to remove duplicate code, even code that shares similarities, I look to refator. Removing duplications is important to adapt more easily to change. When a code change is required, we should only have to make it in one place. The following article will show two relatively simple means to address this code smell, delegates and an Aspect-Oriented approach.

The example I am using in this article is seen below. It is a unit test class, StackFixture class, and it is extremely trivial. This is a typical unit test taken from Test-Driven Development in Microsoft .NET. I have added the logging functionality as an easy means to show how these types of DRY violations can occur. While the duplications in this example deal with logging, they could pertain to other, more complex, functionality as well. The approaches to removing duplications across methods in this article can work with these simple scenarios, as well as more complex ones.

Take for example this sample test case. Each test method logs a message before and after executing the test logic. This violates DRY. We want to keep our test logic in our method, but factor out the duplicate logging. Again, if we were not logging, but doing some repetitive logic, we could factor that out as well.

   1: [TestFixture]

   2: public class StackFixture : AbstractBaseFixture

   3: {

   4:     private Stack stack;

   5: 

   6:     [SetUp]

   7:     public void SetUp()

   8:     {

   9:         stack = new Stack();

  10:     }

  11: 

  12:     [Test]

  13:     public void Empty()

  14:     {

  15:         Log.Info("Starting Empty test");

  16:

  17:         Assert.IsTrue(stack.IsEmpty);

  18:

  19:         Log.Info("Ending Empty test");

  20:     }

  21: 

  22:     [Test]

  23:     public void PushOne()

  24:     {

  25:         Log.Info("Starting PushOne test");

  26: 

  27:         stack.Push("first element");

  28:         Assert.IsFalse(stack.IsEmpty, "After Push, IsEmpty should be false.");

  29: 

  30:         Log.Info("Ending PushOne test");

  31:     }

  32: 

  33:     [Test]

  34:     public void Pop()

  35:     {

  36:         Log.Info("Starting Pop test");

  37: 

  38:         stack.Push("first element");

  39:         stack.Pop();

  40:         Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  41: 

  42:         Log.Info("Ending Pop test");

  43:     }

  44: 

  45:     [Test]

  46:     [ExpectedException(typeof(InvalidOperationException))]

  47:     public void PopEmptyStack()

  48:     {

  49:         Log.Info("Starting PopEmptyStack test");

  50: 

  51:         stack.Pop();

  52: 

  53:         Log.Info("Ending PopEmptyStack test");

  54:     }

  55: }

Remove Duplications with Delegates

Quite simply, we can remove our method duplications using a delegate, in this case, the System.Action delegate. Thanks to Ayende for helping me understand this option. We create a method, TestMethod (as shown below), and add it to our StackFixture class. The method takes two strings (string beforeMessage and string afterMessage) and the Action delegate, representing the test method logic. We will call this method within our test cases.

   1: public void TestMethod(string beforeMessage, string afterMessage, Action action)

   2: {

   3:     // before

   4:     Log.Info(beforeMessage);

   5:

   6:     // invoke our method

   7:     action();

   8:

   9:     // after

  10:     Log.Info(afterMessage);

  11: }

Then, in our tests, we replace the following test method…

   1: [Test]

   2: public void Pop()

   3: {

   4:     Log.Info("Starting Pop test");

   5: 

   6:     stack.Push("first element");

   7:     stack.Pop();

   8:     Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

   9: 

  10:     Log.Info("Ending Pop test");

  11: }

With the same method using our delegate approach.

   1: [Test]

   2: public void Pop()

   3: {

   4:     TestMethod("Starting Pop test", "Ending Pop test",

   5:                delegate

   6:                    {

   7:                        stack.Push("first element");

   8:                        stack.Pop();

   9:                        Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  10:                    });

  11: }

We can replace each of our test methods with the same TestMethod using the System.Action delegate. It will then easy to omit our before and after strings replacing them with “action.Method.Name,” or some other intelligent logic to determine what to log.

This approach works well, but delegates are often difficult to understand. If this solution suits your needs, make sure the implementation is easily maintainable. What is nice about this approach is how simple it is. There is no need to reference any assemblies outside of the .Net framework, i.e. no third party dependencies.

The Aspect-Oriented Approach

Aspect-Oriented Programming (AOP) is an entirely different animal. It certainly deserves more than just a blog post. Please read more about it online. This article will not explain the details of AOP.

If you are reading this, welcome back. I will assume you are now familiar with AOP. There are several options for AOP frameworks. Some frameworks I have used are Spring.net, Castle Project, and PostSharp. The former two provide IoC capabilities as well. I suggest using a well-supported framework, one with community support and frequent updates. Investigate for yourself, there are several nice options available.

AOP with Castle DynamicProxy

Hamilton Verissimo put together a good sample using Castle’s DynamicProxy. It is a nice, clean implementation.This worked fine for me and would work well in other situations. However, in my scenario, if I were to use this approach, I needed to have each of my test classes extend from MarshalByRef. In addition, I would need to modify the underlying NUnit framework to create my proxies in order to provide advice. Since I could not do the latter, or did not want to investigate, I searched for other AOP options.

The DynamicProxy aproach to solving your AOP needs is a great option. It just did not work in my situation, only because NUnit executes each of my methods. I would need to somehow intercept the creation of my test class, create a proxy of it, and execute the test methods on it.

AOP with PostSharp

Gael Fraiteur’s PostSharp is a great option for AOP needs. It is extremely clean and easy to use. It is the simplest AOP framework I have used. I suggest watching Gael’s video tutorial.

The first thing I needed to do, besides downloading and installing PostSharp, is to add two references to my project, PostSharp.Laos and PostSharp.Public. After that, I create a simple class extending OnMethodInvocationAspect, called LoggingMethodInvocationAspect.

   1: [Serializable]

   2: public sealed class LoggingMethodInvocationAspect : OnMethodInvocationAspect

   3: {

   4:     private ILogger log;

   5: 

   6:     public LoggingMethodInvocationAspect(ILogger logger)

   7:     {

   8:         log = logger;

   9:     {

  10: 

  11:     public override void OnInvocation(MethodInvocationEventArgs eventArgs)

  12:     {

  13:         // before

  14:         log.Info("OnInvocation Before proceed");

  15: 

  16:         // invoke

  17:         eventArgs.Proceed();

  18: 

  19:         // after

  20:         log.Info("OnInvocation After proceed");

  21:     }

  22: }

At this point, all we need to do is apply our aspect on target methods. The “AttributeTargetMembers” attribute can use wildcards. This tells the AOP framework to only intercept those methods in the “MathService” class that start with “Test.” Below is the sample where I specify the target assembly, target type (class or classes to intercept), and target methods to intercept. There are many features beyond what I am showing so do further investigation.

   1: [assembly: ClassLibrary.SampleInterfaces.LoggingMethodInvocationAspect(

   2:     AttributeTargetAssemblies = "ClassLibrary.UnitTesting.Sandbox",

   3:     AttributeTargetTypes = "ClassLibrary.UnitTesting.Sandbox.MathService",

   4:     AttributeTargetMembers = "Test*")]

Finally, my StackFixture class now looks something like this. Notice that the duplicate logging logic is now removed and each test method is prefixed with “Test” in the method name. This is so that PostSharp can filter what methods to intercept.

   1: [assembly: ClassLibrary.SampleInterfaces.LoggingMethodInvocationAspect(

   2:   AttributeTargetAssemblies = "ClassLibrary.UnitTesting.Sandbox",

   3:   AttributeTargetTypes = "ClassLibrary.UnitTesting.Sandbox.MathService",

   4:   AttributeTargetMembers = "Test*")]

   5:

   6: [TestFixture]

   7: public class StackFixture

   8: {

   9:     private Stack stack;

  10: 

  11:     [SetUp]

  12:     public void SetUp()

  13:     {

  14:         stack = new Stack();

  15:     }

  16: 

  17:     [TearDown]

  18:     public void TearDown(){}

  19: 

  20:     [Test]

  21:     public void TestEmpty()

  22:     {

  23:         Assert.IsTrue(stack.IsEmpty);

  24:     }

  25: 

  26:     [Test]

  27:     public void TestPushOne()

  28:     {

  29:         stack.Push("first element");

  30:         Assert.IsFalse(stack.IsEmpty, "After Push, IsEmpty should be false.");

  31:     }

  32: 

  33:     [Test]

  34:     public void TestPop()

  35:     {

  36:         stack.Push("first element");

  37:         stack.Pop();

  38:         Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  39:     }

  40: 

  41:     [Test]

  42:     [ExpectedException(typeof(InvalidOperationException))]

  43:     public void TestPopEmptyStack()

  44:     {

  45:         stack.Pop();

  46:     }

  47: }

The end result, a StackFixture test class with duplicate logging logic removed. The PostSharp AOP framework post-processes the compiled assembly and inserts itself, easily providing points of interception.

The PostSharp approach does involve a third-party dependency, but I feel like it is cleaner than the delegate approach. Gael informed me future versions of PostSharp will provide a more configurable solution than adding the [assembly ...] reference for the aspects, perhaps an XML configuration option. This can be done today, but involves some work.

Whether you use delegates, AOP, or some other approach, remove duplicate code wherever possible. I am happy to use either approach in my projects. There are tradeoffs to either solution, so investigate for yourself.