• Visual Studio Tips & Tricks by Zain Naboulsi: Zain covered some useful Visual Studio tips and tricks that he has been outlining on twitter and his blog lately. Of course, the most remarkable shortcut he showed (and nobody in the audience knew about) was that pressing F7 in a command prompt gives a dropdown of all previously executed commands .
• Delightful forms plug-in for Ruby On Rails: The speaker outlined his inspiration behind this forms plug-in, and the output looked very clean and user friendly.
• The CAP theorem by Michael Perry: Michael gave an overview of the CAP theorem (only 2 out of 3 features from the list of Consistency, Availability and Partition Tolerance can be achieved at one time for a distributed computer system).
• NoSQL/MongoDb 101.
• FolderTrack application overview.
• Less CSS: allows use of variables, mixins and nested rules in CSS.
• Windows Phone 7 overview by Chris Koenig.
• SEO optimization and hacks: This was my favorite session for the day and the presenter showed very impressive hacks and examples for manipulating SEO.
• Targeting Mobile CSS media.
• Overview of DallasMakerSpace community: Another cool presentation about the hackerspace community in Dallas.
• My BDD talk.

A big thanks to the organizers for putting this up and I look forward to attending this next year.

1. Screen Protector: I bought the glossy screen MBP, and that turned out to be a big mistake since I  frequently hack at coffee shop/restaurant patios and the glossy screen made the code unreadable. This Moshi iVisor screen protector fixed that and gave the screen a matte finish. It was also very easy to apply without any air bubble issues.
2. Keyboard Cover: I bought the keyboard cover after it showed up in my Amazon recommended products list (probably because the screen protector is from the same company), and I have been pleasantly surprised with it. It is quite thin and does not take much time to get used to. It has also already saved me from serious trouble once when I spilled Diet Coke on the keyboard.
3. Spare Apple MagSafe Power Adapter: I haven’t been able to find a good docking solution for the MBP, but carrying a spare power adapter saves me the trouble of crawling under the desk every day to plug/unplug it.
4. Apple MagSafe Airline Adapter: I have already flown to India (>20 hour flying time) twice this year, and the airline adapter is a lifesaver for such long flights. Just make sure you get a seat with a power port (I use www.seatguru.com to choose good seats), and you are good to go.
5. mStand Laptop Stand: I use this at home, and find it to be quite elegant looking. It also has a gap at the front for easy access to the laptop lid for opening/closing.

I have been meaning to check out the HyperMac external battery, looks like a great product if you go to conferences frequently, or are a road warrior. If any of you have tried it out, please do leave a comment about your experience with it.

However, when I add reference for the Workflow service in the NT Service, no new activities are available in a workflow inside the NT Service project. It looks like Visual Studio parses the service reference differently based on the type of client project. I ended up comparing the csproj files manually for my console workflow client and NT service workflow client. By copying the following entry to the NT service project file, I was able to get it to behave consistently:
<ProjectTypeGuids>{32f31d43-81cc-4c15-9de6-3fc5453562b6};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

It seems that the first guid represents a workflow project type and the second one stands for a Windows C# project.

In case you are subscribed to the old RSS feed URL, please be sure to update it to the new one.

1. You cannot use ‘localhost’ from inside the emulator to refer to your local PC. You have to use either the computer name or the IP address. However, even after I use the computer name, I get this when trying to access a local resource.
   
2. The Windows firewall blocks the emulator from accessing anything on port 80 by default. I had to pull up the Windows Firewall settings and create a new Inbound Rule (I am using 64-bit Windows 7 here). The screenshots below should be self-explanatory.
   
   

And Voila! The emulator is now able to access local resources.

The code that we developed during the talk can be downloaded here.

This is the second part of the 2 post series on Mocking. In the last post, we discussed the basics of Mocking and how Adam (the intern) used Manual Mocking to unit test the simple Shopping Cart application he’s building. In this post, we’ll see how using a Mocking library can make the process of mocking out dependencies simpler.

Why use a mocking library?
The projects you work on are usually nowhere as simple/small as the Shopping Cart example Adam is working on (If they are, is there room for one more on the team?). If you have to build a new mock class for each of your classes, the amount of new code you have to write increases significantly. Also, you might want to reuse your test infrastructure across different classes, or just want the mock object to act dumb.

It’s also harder to do interaction based testing using Manual Mocks. In the manual mock for Logger, we had to add a new field to track how many times it is called. As the behavior to test becomes complicated, so does your mock class. Using a mocking library can take care of all these mundane things.

 Why MOQ?
MOQ is a simple and easy to learn mocking library for .NET that takes advantage of .NET 3.5 (i.e. Linq expression trees) and C# 3.0 features (i.e. lambda expressions). There are other mocking libraries like RhinoMocks and TypeMock Isolator, and MOQ is relatively new to the scene. The main reason I recommend using MOQ is because it has a really low learning curve and is intuitive to use. Unlike other libraries, it does not force you to distinguish between a mock and a stub, which makes it easier for developers new to mocking to work with.

MOQ Basics
To create a mock of type T, you will use the Mock<T> class. Any interface type can be used for mocking, but for classes, only abstract and virtual members can be mocked. Let’s walk through a few common scenarios and the corresponding MOQ usage.

Creating Mock objects

 Mock<IProduct> _mockProduct = new Mock<IProduct>();

 Mock<ILogger> _mockLogger = new Mock<ILogger>();

Mocking a method implementation and returning fake data

 _mockProduct.Setup(m => m.GetProductCategory()).Returns("Test Category");

Mocking a property and returning fake data

_mockProduct.SetupGet(m => m.Name)

            .Returns("Product 1");

Throw exception

 _mockLogger.Setup(m => m.Log(It.Is<string>(p => p == null)))

            .Throws(new ArgumentNullException());

Validate Parameters

 _mockLogger.Setup(m => m.Log(It.IsRegex("[1-9]+")))

            .Callback(() => Console.WriteLine("Numbers passed"));

Verify Interactions

 _mockLogger.Object.Log("test");

 _mockLogger.Verify(m => m.Log(It.Is<string>(s=>s=="test")),Times.Once());

Invoke Callback

 int counter = 0;

 _mockLogger.Setup(m => m.Log(It.IsAny<String>())).Callback(() => counter++);

Even if you are new to MOQ, you’ll find the API very intuitive and easy to pick up.

Back to the Shopping Cart

So Adam sees how easy it is easy to work with MOQ and how much code/effort it saves him, and he updates his unit tests for the Shopping Cart accordingly. Note that these unit tests are independent of the manual mock classes as well as from external resources like the filesystem/database.

   1:  [TestMethod]

   2:  public void AddProduct_AddingProductWithPrice10_ShouldMakeTotal10()

   3:  {

   4:      var mock = new Mock<IProduct>();

   5:      mock.SetupGet(m => m.Price).Returns(10.00M);

   6:      var cart = new ShoppingCart(null);

   7:      cart.AddProduct(mock.Object);

   8:      Assert.AreEqual(10.00M, cart.Total);

   9:   

  10:  }

  11:   

  12:  [TestMethod]

  13:  public void AddProduct_AddingProduct_ShouldCallLogger()

  14:  {

  15:      var mockProduct = new Mock<IProduct>();

  16:      var mockLogger = new Mock<ILogger>();

  17:      mockLogger.Setup(m => m.Log(It.IsAny<string>())).Verifiable("Log should have been called");

  18:      var cart = new ShoppingCart(mockLogger.Object);

  19:      cart.AddProduct(mockProduct.Object);

  20:      mockLogger.Verify();

  21:  }

Later….

You are satisfied with the ShoppingCart project and the corresponding tests that Adam built. When you run into him in the evening, you commend him on the nice work and invite him to have a couple of beers with you. As you are sitting at the bar, you glance at the mirror and you see something that makes the hair at the back of your neck stand up. Instead of Adam and you at the bar, it’s just you sitting there with 2 beers in your hand talking to yourself. You then realize that Adam was a figment of your imagination and you might have suffered from some sort of a dual personality disorder (Kind of like Fight Club). Your brain created Adam so that you could face your fears and misconceptions about Unit Testing and Mocking. On the bright side, you realize that you have finished your project and are sitting in a bar with 2 beers. Cheers!

Download Code

This 2 part blog post series is based on a talk I gave at the Dallas C# SIG last month. In this post, I describe general mocking concepts that are independent of mocking frameworks. In the next post, I’ll describe how using a mocking framework (like MOQ) can reduce development time and effort.

You are probably familiar with Unit Tests, but let’s spend a little time revisiting them. As per Roy Osherove 
              “A unit test is a fast, in-memory, consistent, automated and repeatable test of a functional unit-of-work in the system.”
This is different from writing Integration Tests, which can talk to external resources such as the filesystem, webservices, database and are inherently slow. A common mistake is to create a Unit Test Suite but fill it with Integration tests. This increases the test execution time and discourages developers from running the Unit Tests on a regular basis (Ideally, each time before checking in code or more frequently).

For the purpose of this series, lets assume that you are a senior developer at a firm with plenty of work on your hands. Your pointy haired manager stops by to tell you that he has a new project for you. Seeing that you are busy, he offers to assign you an intern, Adam. You reluctantly agree and talk to Adam who seems like a sharp, reserved guy with a good grasp over OOPs concepts. You go over the project requirements with him, which consist of building a simple Shopping Cart. The Shopping Cart should

1. have the capability to add a product and update price accordingly,
2. have some sort of logging functionality.

Adam seems confident that he can build this project, When asked about Unit Testing, he admits not having any prior experience with it. You tell him to look it up, and write Unit Tests for his code as well. So Adam goes into his cave, and starts working on the Shopping Cart app.He informs you after 2 days that he has now completed the application and his code is ready for review. The basic design looks like this

The code for the ShoppingCart class is pretty simple. It has a Total property denoting the total price of the Shopping Cart, and an AddProduct() function, which adds the price of the product to the total and logs a message. The logger object is passed to the ShoppingCart via constructor injection. Also, the ShoppingCart is coded against IProduct and ILogger interfaces rather than concrete implementations, which makes testing easier.

   1:   public class ShoppingCart

   2:      {

   3:          public ShoppingCart(ILogger logger)

   4:          {

   5:              this._logger = logger;

   6:          }

   7:   

   8:          private ILogger _logger;

   9:          public decimal Total { get; set; }

  10:   

  11:          public void AddProduct(IProduct product)

  12:          {

  13:              Total = Total + product.Price;

  14:              if (_logger != null)

  15:                  _logger.Log(String.Format("Product {0} has been added.",product.Name));

  16:          }

  17:      }

We don’t really care about the Logger and Product implementation, but just know that the Logger logs to a text file in “C:\temp”, and the Product class retrieves the product’s price from the database. Adam has created 2 unit tests, one to check that the Shopping Cart updates its price correctly, and the second one to ensure that logging is done.

   1:          [TestMethod]

   2:          public void AddProduct_AddingProductWithPrice10_ShouldMakeTotal10()

   3:          {

   4:              var target = new ShoppingCart(null);

   5:              //make sure product with ID =1 in database has Price = 10.00

   6:              var product = new Product {ID = 1, Name = "Product1"};

   7:              target.AddProduct(product);

   8:              Assert.AreEqual(target.Total, 10.00M);

   9:          }

  10:   

  11:          [TestMethod]

  12:          public void AddProduct_AddingProduct_ShouldCallLogger()

  13:          {

  14:              var logger = new Logger();

  15:              var target = new ShoppingCart(logger);

  16:              var product = new Product {ID = 2, Name = "Product2"};

  17:              target.AddProduct(product);

  18:              //Open log file and make sure corresponding log was added.

  19:          }

Clearly, his Unit Tests leave a lot to be desired. They depend on the state of the database and the filesystem and therefore are not fast or in-memory. For the same reasons, they are also not repeatable or automated. These are in fact, more close to Integration Tests than Unit Tests. This is a very common mistake. You advise him to mock his dependencies, and since the ShoppingCart class interacts with interfaces rather than concrete implementations, this should be easy to accomplish.

Adam now understands what he is doing wrong, and works on isolating his unit tests to test only the ShoppingCart class. He creates new implementations for IProduct and ILogger that he can use for Unit Testing. Note that in the new implementations, he only has to put in logic needed to get his unit tests to work.

   1:      public class ProductStub:IProduct

   2:      {

   3:          public string Name { get; set; }

   4:          public decimal Price { get; set; }

   5:          public string GetProductCategory()

   6:          {

   7:              throw new NotImplementedException();

   8:          }

   9:      }

  10:      public class LoggerMock:ILogger

  11:      {

  12:          public int NumberOfTimesLoggerCalled { get; set; }

  13:          public void Log(string text)

  14:          {

  15:              NumberOfTimesLoggerCalled++;

  16:          }

  17:      }

And he revises his Unit Tests accordingly

   1:          [TestMethod]

   2:          public void AddProduct_AddingProductWithPrice10_ShouldMakeTotal10()

   3:          {

   4:              var cart = new ShoppingCart(null);

   5:              var stubProduct = new ProductStub(){Price=10.00M};

   6:              cart.AddProduct(stubProduct);

   7:              Assert.AreEqual(cart.Total, 10.00M);

   8:          }

   9:   

  10:          [TestMethod]

  11:          public void AddProduct_AddingProduct_ShouldCallLogger()

  12:          {

  13:              var loggerMock = new LoggerMock();

  14:              var cart = new ShoppingCart(loggerMock);

  15:              int oldNumberOfTimes = loggerMock.NumberOfTimesLoggerCalled;

  16:              cart.AddProduct(new ProductStub());

  17:              Assert.AreEqual(oldNumberOfTimes + 1, loggerMock.NumberOfTimesLoggerCalled);

  18:          }

Adam’s Unit Tests now pass and he has done a good job of keeping them free from external resources such as the filesystem or database by manually mocking his classes. Note how the first Unit Test uses the new IProduct implementation (a Stub) to support the Unit Test but asserts against the Shopping Cart object, whereas the second one asserts against the new ILogger implementation (a Mock).

In the next post, we’ll see how Adam can achieve the same granularity in his Unit Tests by using a mocking framework rather than creating manual mocks.

Download Code.

Part 2.

• Bootstrapping your business session with Nate Kohari and James Avery: I have great respect for entrepreneurs, and more so for those with a coding background. Nate and James shared things that worked for them in their ventures, and a lot of things that didn’t. The session was very interactive, and a great start to the conference for me.
• Ruby/IronRuby: One of my goals for going to CodeMash was to decide if I am going to spend any significant amount of time trying to learn Ruby/IronRuby this year. The passion that a lot of the developers (especially the EdgeCase folks)  had for Ruby was definitely contagious and hard to ignore. I ended up attending a couple of Ruby sessions and I hope to spend more time with it in the next couple of months. The best Ruby session for me was “Ruby and Rails for the .Net developer” by Matt Yoho.
• Meeting more geeks: I got to meet a bunch of great people I knew from twitter, and some more.
• Amazon Ninja puzzles: Amazon had the best vendor booth IMO. They had programming related puzzles for you to solve, and I found myself in front of the question board every few hours (even missed some sessions because of this . This is me hacking away in the halls with the Amazon Ninjas next to my laptop.
• Enter the Haggis concert: There was a live concert by Enter the Haggis on Thursday night, and they played some great fusion music. This was an awesome way to unwind.

There was plenty of food and caffeine at the conference, though the Wifi could have been better. Thanks to all the organizers for doing such a great job. I hope to be there again next year.

I’ll be presenting at the Dallas C# SIG later today, and am uploading a draft of the code and slides, in case somebody wants to work on the code during the presentation. I’ll update the attachment after the presentation if there are any changes.

Download here.