• Assembly Language
• C
• C++
• C#
• JavaScript
• Visual Basic/VB.NET
• (edit - and how could I forget the early years of my career with PL/I on the DEC VAX?!? - apparently pretty easily, since it didn't even cross my mind. Suppressed memories, I think.)

• C#
• JavaScript (more client-side than Node.js servers)
• VB.NET (though this one's fading fast)

• TypeScript
• Python
• F#

• working with interfaces for more than just testing reasons,
• or your component objects cross process boundaries,
• or calls against your component have are not idempotent (likely using a shim)

In fact, it seems that we don't even have to wait on the compile cycle at all anymore to get feedback on whether the code we just wrote is working.  At least not with NCrunch.  If you haven't discovered NCrunch yet, I'm sorry for you, because it's now my second favorite Visual Studio extension next to ReSharper.  NCrunch continually runs your tests as you type them.  No need to even CTRL-SHFT-B, much less CTRL-R, A. This is almost instantaneous feedback on the last character you typed in your code.  And it's even smarter than that.  Before I had ever used NCrunch I used to think that it simply would save me from having to type CTRL-R, A.  Not so.  You'll find yourself pondering whether this is almost a new paradigm - this instantaneous feedback.

Of course, you can still write terrible tests and rob yourself of instantaneous feedback.  NCrunch can run integration tests, which tend to take longer (not that integration tests are bad, they're essential!), but NCrunch's usefulness is primarily in running your quick unit tests for immediate feedback.  So have NCrunch ignore those long-running tests and get instant feedback on success/failure, code coverage, and profile times of your tests.  You can un-ignore your long-running tests (or just CTRL-R, A) every once in a while to confirm you haven't broken integration before pushing your changes to your main source control.

NCrunch isn't perfect, and there's plenty of room for stability improvements (or maybe I just don't know how to set it up correctly), but I'd rather have a rocket-ship that I have to get out and kick every once in a while than have a horse and buggy that plods along forever.  At some point the "Tortoise and the Hare" analogy breaks down, and the NCrunch bunny definitely breaks the analogy.

Now, on to the true purpose of this post.  Because of the instantaneous feedback that NCrunch gives you, you can almost treat it like a REPL.  Using this technique I find myself going into the debugger even less than I did after adopting TDD.  Not sure what you need to do with a specific class in the Base Class Library?  Need to "spike" a test?  Try simply putting one or two judicious uses of Debug.Print() and look at the NCrunch Tests window. Select your test (you have to select the "checkbox over the eyeball" toolbar button to show passing tests) and in the gray area below you'll see the debug output of your test.  Not what you expected?  Change your code, try a new method from the object's IntelliSense list - all things that are much harder to do when debugging.  You'll get feedback faster and learn faster.

For example, I had some data that I wanted to verify inside of a SOAP Message response, but I didn't really know what data was in there.  To me, it looked like angle brackets and namespaces had exploded everywhere (ah the joys of SOAP).  Then I thought of Linq-to-XML.  I knew little more about Linq-to-XML than the simple fact that it exists.  A quick Bing of some MSDN docs as an overview of Linq-to-XML showed me the basics. So now it's time to experiment.

It was simple.  Like I said, just create a test and in the NCrunch Tests window, select the test and watch the test output area as you edit the test (notice the current name of the test reflects my ignorance of what I'm wanting to test, not strict TDD, no, but that's what happens when you're "spiking"):

        [TestMethod]
        public void WhenCtorInvoked_ThenMessageShouldBeUhhhhhhh()
        {
            var context = new EnumerationContext();
 
            var sut = new PullMessage(context, 50);
 
            var element = sut.Message.GetBody<XElement>();
            Debug.Print(element.ToString());
        }

Still quite a few angle brackets, but certainly not as bad as the whole SOAP message!

Hope this helps,
Doug

A lot of the confusion around exceptions comes about if you’ve ever actually tried to serialize an exception using an Xml-based serializer.  You are testing the code you write, correct? When attempting to serialize your nice new exception class with something like XmlSerializer, the serializer will simply choke, stating that it can’t serialize any class that has an IDictionary member.  And System.Exception has an IDictionary in it.  Yet every piece of literature coming out of Microsoft says that we should build custom exceptions (sub-typed from Exception, and not ApplicationException) and mark them as [Serializable].  What gives?  Well, there are more serializers in the world than just the XML-based serializers, and that’s when it’s important to serialize exceptions.  The System.Runtime.Serialization.Formatters.Binary.BinaryFormatter, for example, serializes exceptions just fine.

So, how do you derive from Exception correctly, particularly if you’ve got additional information in your custom exception class?  I thought you’d never ask.

    [Serializable]
    public class AuthorizationRequiredException : Exception
    {
        public string ResourceReferenceProperty { get; set; }
 
        public AuthorizationRequiredException()
        {
        }
 
        public AuthorizationRequiredException(string message)
            : base(message)
        {
        }
 
        public AuthorizationRequiredException(string message, Exception inner)
            : base(message, inner)
        {
        }
 
        protected AuthorizationRequiredException(SerializationInfo info, StreamingContext context)
            : base(info, context)
        {
            ResourceReferenceProperty = info.GetString("ResourceReferenceProperty");
        }
 
        [SecurityPermission(SecurityAction.Demand, SerializationFormatter = true)]
        public override void GetObjectData(SerializationInfo info, StreamingContext context)
        {
            if (info == null)
                throw new ArgumentNullException("info");
            info.AddValue("ResourceReferenceProperty", ResourceReferenceProperty);
            base.GetObjectData(info, context);
        }
 
    }

  And here are the tests that drive it to completion (updated to show better testing methods):

    [TestClass]
    public class AuthorizationRequiredExceptionTests
    {
        [TestMethod]
        public void AuthorizationRequiredException_default_ctor()
        {
            // Arrange
            const string expectedMessage = "Exception of type 'MyApp.Exceptions.AuthorizationRequiredException' was thrown.";
 
            // Act
            var sut = new AuthorizationRequiredException();
 
            // Assert
            Assert.IsNull(sut.ResourceReferenceProperty);
            Assert.IsNull(sut.InnerException);
            Assert.AreEqual(expectedMessage, sut.Message);
        }
 
        [TestMethod]
        public void AuthorizationRequiredException_ctor_string()
        {
            // Arrange
            const string expectedMessage = "message";
 
            // Act
            var sut = new AuthorizationRequiredException(expectedMessage);
 
            // Assert
            Assert.IsNull(sut.ResourceReferenceProperty);
            Assert.IsNull(sut.InnerException);
            Assert.AreEqual(expectedMessage, sut.Message);
        }
 
        [TestMethod]
        public void AuthorizationRequiredException_ctor_string_ex()
        {
            // Arrange
            const string expectedMessage = "message";
            var innerEx = new Exception("foo");
 
            // Act
            var sut = new AuthorizationRequiredException(expectedMessage, innerEx);
 
            // Assert
            Assert.IsNull(sut.ResourceReferenceProperty);
            Assert.AreEqual(innerEx, sut.InnerException);
            Assert.AreEqual(expectedMessage, sut.Message);
        }
 
        [TestMethod]
        public void AuthorizationRequiredException_serialization_deserialization_test()
        {
            // Arrange
            var innerEx = new Exception("foo");
            var originalException = new AuthorizationRequiredException("message", innerEx) { ResourceReferenceProperty = "MyReferenceProperty" };
            var buffer = new byte[4096];
            var ms = new MemoryStream(buffer);
            var ms2 = new MemoryStream(buffer);
            var formatter = new BinaryFormatter();
 
            // Act
            formatter.Serialize(ms, originalException);
            var deserializedException = (AuthorizationRequiredException)formatter.Deserialize(ms2);
 
            // Assert
            Assert.AreEqual(originalException.ResourceReferenceProperty, deserializedException.ResourceReferenceProperty);
            Assert.AreEqual(originalException.InnerException.Message, deserializedException.InnerException.Message);
            Assert.AreEqual(originalException.Message, deserializedException.Message);
        }
 
        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void AuthorizationRequiredException_GetObjectData_throws_exception_when_info_null()
        {
            // Arrange
            var sut = new AuthorizationRequiredException("message") { ResourceReferenceProperty = "MyReferenceProperty" };
 
            // Act
            // ReSharper disable AssignNullToNotNullAttribute
            sut.GetObjectData(null, new StreamingContext());
            // ReSharper restore AssignNullToNotNullAttribute
 
            // Assert
            // [ExpectedException(typeof(ArgumentNullException))]
        }
    }

If you use this code as a template for creating your custom exceptions, you won’t go too far wrong, I think.

As far as XML-based serializers goes, I hope that the Base Class Library team will take some time and just fix the "chokes on IDictionary" issue.  Frankly, it's quite embarrassing.

X as a Service

"Software as a Service" (SaaS), "Platform as a Service" (PaaS), "Infrastructure as a Service" (IaaS); the computing world is absolutely going the way of subscription "services" - the cloud.  So what does Windows Azure offer?  Well, if you count Office 365, all of them.  If not, then it offers both PaaS and IaaS, with IaaS receiving the most press, recently, as it fills a gap in more easily allowing "Private Cloud" users to migrate to the "Public Cloud"

How Do I Start?

Well, first you'll need a Windows Azure subscription.  At the time of this writing, you can get a free 90-day subscription at https://www.windowsazure.com/

Next, you'll need something to deploy software to Windows Azure with.  The easiest to get started with is Visual Studio 2012 at https://www.microsoft.com/visualstudio/en-us.

“warning: hg.codeplex.com certificate with fingerprint 1c:ef:1d:4f:55:57:5b:8c:ab:78:a1:72:2c:d2:1b:56:fd:64:03:19 not verified (check hostfingerprints or web.cacerts config setting)”

…are a bit monotonous.

And they’re probably supposed to be.  However, it is pretty simple to get rid of such warnings.  All you need to do is edit your mercurial.ini file.  On Windows 7, this can be found at C:\users\[your account]\mercurial.ini.  Or, if you’re using TortoiseHg, Open “Files | Settings” and click the “Edit File” button in the upper right corner.  Then you just add the following two lines to that file:

[hostfingerprints]
hg.codeplex.com = 1c:ef:1d:4f:55:57:5b:8c:ab:78:a1:72:2c:d2:1b:56:fd:64:03:19

Of course, this example assumes you’re referencing the CodePlex repository.  All the data you need to add to the mercurial.ini file can be found in the warning message you get (bitbucket, etc.)

Basically, it’s like an auto-mocking container (minus the container – there is no dependence on any IoC container). 

Let’s say you’re doing TDD and have a class that you’re building tests for.  Of course, that class is being modified over time – maybe it receives new dependencies, it changes dependencies, or even has some dependencies refactored out.  I’ve been there and when this happens, I have to go through ALL my unit tests for the class and build new mocks for the dependencies and modify the code that instantiates your code under test.  Not fun when you have dozens of tests for a particular class (this assumes you’re not using a SetUp type method, which you can’t do anyway in the case of XUnit.net).

What would be really cool is if there was a way to automatically construct the class you’re testing with all mock dependencies – let the framework figure out what those dependencies are and just build the class itself without the manual work of figuring out dependencies and mocking each one.  Well, there actually are plenty of those out there already – that is, for actual mocking frameworks like RhinoMocks, Moq, etc.  The problem is that Visual Studio 11 has a cool, new mocking and isolation framework called Fakes, and there's no existing "auto mocking" type behavior out in the Internets for this new framework, yet.  Peter Provost talks about a lot of the new VS11 unit testing features, including Fakes, here.  There is also pretty good documentation for Fakes (at least for beta software) at MSDN.

Given that you understand what using the Fakes Framework is like, you could create a test method something like following example:

        [TestMethod]
        public void ConnectorManagerCanGetConnectors()
        {
            // Arrange
            // ConnectorManager has a dependency - IConnectorRepository
            var autofake = new AutoFake<ConnectorManager>();
            var stubConnector = new StubIConnector();
            autofake.Get<StubIConnectorRepository>().GetConnectorsString =
                filter =>
                {
                    return new List<IConnector> {stubConnector, stubConnector};
                };


            // Act
            IList<IConnector> result = autofake.Target.GetConnectors("filter");

            // Assert
            Assert.AreEqual(2, result.Count);
        }

Later, if my "ConnectorManager" gains or loses additional dependencies, I don't necessarily have to come back to this test and modify it in any way - AutoFakes will detect the new dependency (an interface or abstract class, right now) and construct the class under test correctly.

If you have suggestions for additions to the framework (AutoFakes, not the general Visual Studio Fakes Framework), go to the AutoFakes Discussion or Issue Tracker, or just add a comment to this blog post.  I’ll make sure the request gets put into the appropriate area.

As it turns out, Cmdlets must have a public default constructor, of course!  I sometimes forget this step when I’m in my TDD rhythm.  So something like this:

using System.Management.Automation;

namespace MyCmdlets
{
    [Cmdlet(VerbsCommon.New, "DooDad")]
    public class NewDooDadCommand : MyBaseCommand
    {
        [Parameter(Position = 0, Mandatory = true)]
        public string MyData { get; set; }

        private readonly IDooDadFactory _dooDadFactory;

        public NewDooDadCommand(IDooDadFactory dooDadFactory )
        {
            _dooDadFactory = dooDadFactory;
        }

        ...
    }
}

Should really look more like this:

using System.Management.Automation;

namespace MyCmdlets
{
    [Cmdlet(VerbsCommon.New, "DooDad")]
    public class NewDooDadCommand : MyBaseCommand
    {
        [Parameter(Position = 0, Mandatory = true)]
        public string MyData { get; set; }

        private readonly IDooDadFactory _dooDadFactory;

        /// <summary>
        /// Need this public default constructor
        /// </summary>
        public NewDooDadCommand()
            :this(ServiceLocator.GetInstance<IDooDadFactory>())
        {}

        public NewDooDadCommand(IDooDadFactory dooDadFactory )
        {
            _dooDadFactory = dooDadFactory;
        }

        ...
    }
}