Most people try to avoid hard things or at least delay them until they have a good reason, but some things, important things… we should do those more often.  We need to practice the hard things.  They in turn become less risky and less scary bookends to our prideful efforts.

Testing is one of those things.

A few months back there was a thread going on the Scrum.org Professional Scrum Developer Trainers list about topics to include in the future.  Specifically this was in regards to the .Net flavor of the course, because we were getting updates about what was coming down the pipe in the tooling.  My excitement in that course has always focused on testing and with Jason Zander announcing continuous testing for all the major test runners in Visual Studio vNext that was my suggestion.

Adam Cogan, a smart dude in his own right, followed up asking me to describe why I thought that was such a big deal.  I sent a rather long reply that I found useful today while describing the testing pyramid to coworker Steve Gentile.  I thought I’d provide that reply here and get everyone’s thoughts:

We give passing credence to the idea of fast tests that run often versus slow tests that we expand to include before checkin/commit or during automated build (gated).  Unfortunately, the later becomes a catch all for the oops, just got lazy scenario. 

I remember when I first got the automated testing bug.  I wrote some tests (calling them unit tests) that integrated with a 3^rd party tool, gave great coverage and awesome feedback.  We knew within 5-10 minutes if a new 3^rd party version could be released.  Giant leap.  The next step, though, was hidden.  I would code for 20, 30, 90 minutes or more and then run my tests while I grabbed a cappuccino.

My current passer-by, rock your world tip/tool is NCrunch for .Net or Guard for everyone else (we need this).  Autotest.Net was the first try from James Avery, but it didn’t have any traction and was unstable at best.  Most teams have tests, but they aren’t using them effectively.   (Ok, Nuget and the no-commit pattern is a very close second!)

I run a group call Cincy Clean Coders.  We do katas, often as a whole group.  The first Randori kata we did was eye opening for the audience.  Someone started refactoring to solve a red test and another person threw a fit.  “What are you doing?!  You’re red!  You can’t refactor when your red.”  The driver didn’t intend to be refactoring, they were just solving the current red test in their mind.  They didn’t realize they were mixing many steps into one.  There is a mental burden to doing the simplest thing, running the tests, and only then refactoring.

Teams make a great jump when they automate their important tests.  Nightly feedback from QTP, Test Pro, or Coded UI is a big step.  Consciously mixing unit, integration and acceptance tests is amazing.  Our current tools mandate the start of the feedback loop be a conscious decision.  “So all those changes, wonder if things are still working?  Let’s find out.”  We don’t say it, but that’s how we act.

When your tests run every time you pause (NCrunch) or save a file (Guard) you come to expect feedback NOW.  You skip even CTRL+R,Y until your “finished”, only to find you just did 3,5, 10 refactorings.  Which one caused the problem?  Or you write a test that calls a web service, taking .65 seconds.  Pretty soon “fast” tests take 30-60 seconds (or more!) and your CI build takes 20 minutes.

Continuous testing is (IMO) the next step in shortening the feedback loop.  You start organizing your tests more effectively (or at all).  In good environments, I even use this as a chance to commit.  I now have the luxury of completely ignoring the path I took to my current source situation.  Get into a tizzy, reset/undo checkout.  Committing 10-20 times in an hour isn’t uncommon here.  Neither is branching half a dozen times.

In the PSD I can demo and talk to the importance of running tests often and having confidence, but a blaring red failure on the screen for that last edit really hits home.

I want your test suite to be an invaluable tool.  Continuous testing is one of those pit of success kind of things.  We need more of those.  But when signals pop up solve the real problem.  Don’t delay the pain.

I’m working on the Caliburn.Micro Nuget package and one of the things that we need is to add a default Bootstrapper, ShellView, and ShellViewModel to your project.  One awesome thing Rob Eisenberg has done is provide WPF, Silverlight and WP7 versions of Caliburn.Micro.  Unfortunately, the platforms are different enough that these three pieces we would like to add are different.

I say this is unfortunate only because Nuget doesn’t support framework and profile specific content through conventions.  That’s only available for binaries.  It does, however, provide hooks into the install process via PowerShell. 

Maybe you see where I’m headed…

The hard part for me was figuring out the framework version of the project targeted.  In the end, here’s how you can pull the TargetFrameworkMoniker in your install.ps1:

param($rootPath, $toolsPath, $package, $project)

  $moniker = $project.Properties.Item("TargetFrameworkMoniker").Value

  $framework= new-object System.Runtime.Versioning.FrameworkName($moniker)

  write-host "Identifier: " $framework.Identifier 
  write-host "Version: " $framework.Version
  write-host "Profile: " $framework.Profile

# WPF4 will be NETFramework,Version=v4.0,Profile=Client
# SL4 will be Silverlight,Version=v4.0
# WP7 will be Silverlight,Version=v4.0,Profile=WindowsPhone

Happy packaging!

I’m happy to announce that our first Professional Scrum Developer course of 2011 is scheduled for February 21st.  This is a course which practices 5 days of craftsmanship, collaboration, and sustainable pace via the Scrum framework.  Practice is the key to success and there is no better way to build a successful Agile team than to work together, continuously with a coach available to guide you through unfamiliar terrain.

Every team has it’s own happy path to a successful, self-organizing, self-managing Scrum team and it is not an easy one to navigate.  During these 5 days we will experience brown-field product development using Modern Engineering Practices such as TDD, Continuous Integration, Refactoring, and more.  Our case study is an ASP.Net MVC application.

Register for the course with MaxTrain.com who graciously provides the facility and infrastructure. 

Scrum.org, founded by Ken Schwaber to improve the profession of software development so that developers love their work and our customers love working with developers, describes the Professional Scrum Developer course in detail.  You’ll also find the course syllabus here.

Look forward to seeing you there.

var shape = _console.AskForShape();

var rectange = GetRectange();

_console.PrintArea(rectange.ComputeArea());
_console.PrintCircumference(rectange.ComputeCircumference());

ReSharper was hinting at it, but it should have screamed.  Why do I need to hang on to shape?  I can imagine my mindset at the time.  I was worried about the inevitable decision I would have to make about 20 tests down the road.  That little assignment was the beginning of my overeager, premature design.

Question your code.

During the late ‘90s and early 2000s immense business systems where built on the powerhouse platform known as Microsoft Office.  Having worked, well, at all, I’ve seen first hand the ugly, but quite impressive apps built by accountants and marketiers (mark it down, that’s my word) generating great revenues or savings for their companies.  I have replied to requests to “make that an enterprise web app” with “that will fail miserably, keep using it.”  The apps are a disaster waiting to happen themselves, but that’s why we have enterprise backup systems.  It’s just not worth the IT Department’s time to rebuild Excel when it is perfectly suited for their purpose.

In come WebMatrix, LightSaber, I mean LightSwitch, and all the other “low-end” tools.  These are obviously a trend that show Microsoft is abandoning the “high-end” developer (are we really that pompous that we consider ourselves “high-end”, get over yourself you geek.  I bet they make more cash per feature than you).  Or could it be that they are making up for the fact that the last great act of feature development shown by Microsoft to the “low-end”, revenue generating, feature shipping developer is the Ribbon Bar.  I guess you could add SharePoint in there, but I won’t bate you. 

Since 2002, we’ve seen 4 iterations of Silverlight, 4 versions of the Framework, WPF, WCF, the rise of PnP, 5 versions of Visual Studio, Azure, Hyper-V, Team Foundation Server (like it or not), and a dearth of other tools in the same time that Excel has received… drum role… the Ribbon.  Yes there are nicer icons to represent values and you can make prettier tables or charts, but seriously they still use VBA!  In that same time period we’ve seen 2, count them, 2 releases of  the platform on which many businesses survive.

So yes, Microsoft has thrown the Excel and Access productivity worker (not lowend developer) a bone.  They’ve made it easier for you to say, “Sorry, I don’t do Master-Details forms.  Here’s WebMatrix, call me when you want to ship.”  Get over it, start an OSS project or, if you liked it so much, help the IronRuby team build that platform up.  Whatever you do, stop whining and do something.

Unlikely. 

ReSharper, on the other hand, has taken the Switzerland approach and tries to be true to each testing frameworks settings and run modes.  It has a gap in regards to MSTest at this point, though.  (Who uses MSTest you say?  Lots of people.  You wanted unit testing to become common place, remember?  Stop complaining.)  ReSharper gives you this nasty warning when running your MSTests with Code Coverage enabled.

See MSTest is actually pretty sweet when it comes to data capture.  It might not be blazing fast, but it lets you capture an awful lot of information in different situations.  In order to support those different situations nicely there is this file type called Test Settings (*.testsettings).  Test Settings files live in your solution folder and you can have a bunch of them.  In fact, Visual Studio 2010 gives you two by default: Local.testsettings and TraceAndTestImpact.testsettings. 

Local.testsettings doesn’t capture anything by default, but one of the first thing everyone tends to look for when running tests is code coverage.  Since Local.testsettings are their default and people don’t realize you can change your active test settings they open Local.testsettings, choose Data and Diagnostics and check Code Coverage (and probably other things that sound interesting).

Now you’ve eliminated Resharper as a Test Runner.  But you don’t have too!  Remember how I said you can have a bunch of those .testsettings files and eluded to the fact that one can be made Active.  Here’s what you’re going to do:

1. Right click the Solution Items folder (don’t put them in a different solution folder, VS doesn’t like that, sorry).
2. Click Add –> New Item
3. Under Installed Templates (VS 2010) select Test Settings.
4. Name the new file ReSharper.testsettings (or whatever makes you happy really) and click ok.

The Test Settings editor dialog will come up, but you don’t need to change a thing if you don’t want or need.  Data and Diagnostics will be empty which is good for ReSharper.  At this point, you can go to the Test menu option, open Select Active Test Settings and choose your new settings (ReSharper.testsettings in our example).

That’s it, use ReSharper all you like.  There are some other nice things that ReSharper will do for you in regards to abiding by deployment options for content files and things like that, but we’ll save that for a different day.  Here’s a quick video that highlights everything I’ve outlined here.

What is the Strategy Pattern

The strategy pattern is a way of isolating what would often be found in a case statement.  The bland example being calculating Sales tax on an Order.  Each state and/or country has its own tax calculation and rather than

   1: public void Process(Order order) {

   2:     switch(order.Country) {

   3:         case "USA":

   4:             order.Total = order.Subtotal * .07;

   5:             break;

   6:         case "Canada":

   7:             order.Total = order.Subtotal * .0985;

   8:             break;

   9:     }

  10: 

  11:     // ...

  12: }

you should be breaking each calculation out into different ITaxStrategy implementations and consuming them like so:

   1: public void Process(Order order) {

   2:     var strategy = _taxStrategyFactory.GetStrategyForOrder(order);

   3: 

   4:     var salesTax = strategy.CalculateSalesTax(order);

   5: 

   6:     order.SalesTax = salesTax;

   7:     order.Total = order.SubTotal + order.SalesTax;

   8: }

The question remains, how to eliminate the conditional logic in TaxStrategyFactory determining which strategy is chosen.  The solution is to set up a convention for discovering the available strategies and delegating the criteria to the Strategy itself.

Discovery

The concept here is that we don’t have to “hook up” any new Tax Strategy to our Processing mechanism, we just “publish” new ones in a known way and they are picked up simply based on their existence.  This is often referred to as Convention Over Configuration.  We accomplish this with Castle Windsor with the Fluent Registration API:

   1: container

   2:     .Register(AllTypes

   3:                   .FromAssembly(Assembly.GetExecutingAssembly())

   4:                   .Where(x => x.Name.EndsWith("Strategy"))

   5:                   .WithService.FirstInterface());

This will register all classes found in the executing assembly which have the suffix “Strategy” as implementing the ITaxStrategy interface.  The second half of convention based discovery is consuming the ITaxStrategy implementations.  We can want to get all of these into the TaxStrategyFactory via a constructor array dependency:

   1: public TaxStrategyFactory(params ITaxStrategy[] taxStrategies)

   2: {

   3:     _taxStrategies = taxStrategies;

   4: }

Unfortunately, Windsor doesn’t support arrays as dependencies by default.  Windsor has the concept of Resolvers (a strategy implementation itself) and we are going to have to tell it about the ArrayResolver which knows how to, err, resolve array dependencies:

   1: container

   2:     .Kernel.Resolver.AddSubResolver(new ArrayResolver(container.Kernel));

Cool, so put these all together in our registration code and we get:

   1: container

   2:     .Register(Component

   3:                   .For<IOrderProcessor>()

   4:                   .ImplementedBy<OrderProcessor>())

   5:     .Register(Component

   6:                   .For<ITaxStrategyFactory>()

   7:                   .ImplementedBy<TaxStrategyFactory>())

   8:     .Register(AllTypes

   9:                   .FromAssembly(Assembly.GetExecutingAssembly())

  10:                   .Where(x => x.Name.EndsWith("Strategy"))

  11:                   .WithService.FirstInterface());

At this point we can kick of the true discovery chain of events through:

   1: var processor = container.Resolve<IOrderProcessor>();

   2: 

   3: processor.Process(order);

Delegating Criteria

So in OrderProcessor.Process we are asked the TaxStrategyFactory for the applicable ITaxStrategy implementation:

   1: var strategy = _taxStrategyFactory.GetStrategyForOrder(order);

   2: 

   3: var salesTax = strategy.CalculateSalesTax(order);

   4: 

   5: //...

  The question is, how did the factory determine which of the boundless implementations applies?  That’s the job of each ITaxStrategy itself.  Here’s the implementation of our factory:

   1: class TaxStrategyFactory : ITaxStrategyFactory

   2: {

   3:     private readonly ITaxStrategy[] _taxStrategies;

   4: 

   5:     public TaxStrategyFactory(params ITaxStrategy[] taxStrategies)

   6:     {

   7:         _taxStrategies = taxStrategies;

   8:     }

   9: 

  10:     public ITaxStrategy GetStrategyForOrder(Order order)

  11:     {

  12:         return _taxStrategies.FirstOrDefault(x => x.IsApplicable(order));

  13:     }

  14: }

Notice how the TaxStrategyFactory depends on all of the ITaxStrategy implementations.  It then uses the ITaxStrategy.IsApplicable(Order) method as criteria for a FirstOrDefault call.  Here’s an example TaxStrategy for any Order with country “USA”:

   1: public class USTaxStrategy : ITaxStrategy

   2:     {

   3:         private static readonly IDictionary<string, double> TaxRates = new Dictionary<string, double>()

   4:                                                                    {

   5:                                                                        {"OH", 7.0},

   6:                                                                        {"MI", 6.25},

   7:                                                                    };

   8:         public double CalculateSalesTax(Order order)

   9:         {

  10:             var rate = TaxRates[order.State];

  11: 

  12:             return (order.SubTotal * (rate / 100));

  13:         }

  14: 

  15:         public bool IsApplicable(Order order)

  16:         {

  17:             return order.Country == "USA";

  18:         }

  19:     }

You can download the sample project that goes along with this here.

Here’s my answer to the problem using Anonymous methods and my first real attempt at creating (versus using) a Fluent Api.

The most common scenario for Undo/Redu support is form completion.  In your Domain or View Model this is often tied to Two Way bound properties.  Take the simple Person class:

public class Person

{

    public string Name { get; set; }

    public DateTime BirthDate { get; set; }

}

The question is how to provide undo/redo support for a form (WPF often in my case) bound to a Person.  First, I create a ViewModel or Presenter for the Person class:

public class PersonViewModel : ViewModelBase

{

    private readonly Person _person;

    public PersonViewModel(Person person)

    {

        _person = person;

    }

    public string Name

    {

        get { return _person.Name; }

        set

        {

            _person.Name = value;

            OnPropertyChanged("Name");

        }

    }

    public DateTime BirthDate

    {

        get { return _person.BirthDate; }

        set

        {

            _person.BirthDate = value;

            OnPropertyChanged("BirthDate");

            OnPropertyChanged("Age");

        }

    }

    public int Age

    {

        get

        {

            var now = DateTime.Now;

            var age = now.Year - _person.BirthDate.Year;

            if (now < _person.BirthDate.AddYears(age))

                age--;

            return age;

        }

    }

}

Notice that we have a calculated property Age based on the BirthDate.  Any time we change BirthDate we want to make sure to notify that the Age is also changed, obviously. 

Here is the Fluent way to register Undo/Redo support for our PersonViewModel.Name property:

   1: public string Name

   2: {

   3:     get { return _person.Name; }

   4:     set

   5:     {

   6:         var oldName = _person.Name;

   7:  

   8:         _undoRedoManager

   9:             .WithUndo(() => _person.Name = oldName)

  10:             .RepeatAfterBoth(() => OnPropertyChanged("Name"))

  11:             .Do(() => _person.Name = value);

  12:     }

  13: }

Cool, but what is that doing?  Well, it’s pretty simply.  We are simply maintaining two queues; An Undo and a Redo queue.  Here is the longer syntax, without the Fluent helper Api that makes that a little clearer:

public string Name

{

    get { return _person.Name; }

    set

    {

        var oldName = _person.Name;

        _undoRedoManager.Push(() =>

                                  {

                                      _person.Name = oldName;

                                      OnPropertyChanged("Name");

                                  },

                                  () =>

                                  {

                                      _person.Name = value;

                                      OnPropertyChanged("Name");

                                  });

    }

}

This may not seem like much more, but if your Repeat part is more than one line, it gets a bit fragile.  Being able to specify the “After” stuff once is important.

From here you can use the IUndoRedoManager.CanUndo(), IUndoRedoManager.CanRedo(), IUndoRedoManager.Redo() methods to go back and forth.  Hook this up to your favorite ICommand implementation and you have most of what you might need.

Here is the full project with a WPF Sample and a VB sample.  The VB version is a little ugly since it doesn’t support anonymous methods without a return, but it works.

If you have suggestions (on the Fluent Api especially) let me know.  I’d really like to hear them.

If you haven’t started to learn how to incorporate this awesome toolset into your daily coding life, you’re killing yourself.  No excuses.

I prefer Dependency Resolution.  I don’t use any fancy framework, I just use a good old, DI.Resolve<IBusyBee>() and go about my business.  It works wonderfully, it’s light-weight (cause I don’t use configuration based DI frameworks), and it’s my baby.

That said, it’s also been the roadblock to my mocking foray.  That was, until I “got it” today.  Long story short, here’s how I roll:

Create a Mock DI Container…

Mock<IDIContainer> mockContainer = new Mock<IDIContainer>();

Create the Injected Mock instances…

Mock<INotificationManager> mockNotifMgr = newMock<INotificationManager>();
Mock<IRepository> mockRepository = newMock<IRepository>();

Tell the mock IDIContainer to return the mock instances when asked…

mockContainer.Expect(c => c.Resolve<INotificationManager>(null)).Returns(mockNotifMgr.Object);
mockContainer.Expect(c => c.Resolve<IRepository>(null)).Returns(mockRepository.Object);

Mock your heart out…

mockNotifMgr.Expect(mgr => mgr.NotifyEmailConfirmation(It.IsAny<Member>())).AtMostOnce();

Member.Register("username", "firstname", "lastname", "ryan@myus.com");

mockContainer.VerifyAll();
mockNotifMgr.VerifyAll();

I’m very happy to have finally jumped on the Moq bandwagon as it will certainly make some unit tests much easier to write.  Maybe I’ll even do the test first part more faithfully now. 

FYI, I use my own DI framework which is just a glorified HashTable.  It works for me and it is quick.  Moq has also become my Mock framework of choice for no good reason other than I downloaded it first.