MrDustpan

Git + Dropbox = Crazy Delicious

2011-09-02T18:57:00.001-07:00

Here’s a nifty trick I learned from a Tekpub video: Use git to push your stuff to a dropbox folder on your machine. That folder is the “master” repository and then it’s automatically synched with Dropbox. You can even share it with other people if you’d like. Here’s how (in git bash):

cd c:/dev/projects/theAwesome
git init
git add .
git commit -am "initial commit"
mkdir c:/dropbox/repos/theAwesome
git remote add origin c:/dropbox/repos/theAwesome
cd c:/dropbox/repos/theAwesome
git init --bare
cd c:/dev/projects/theAwesome
git push origin master

How to Bin Deploy an ASP.NET MVC 3 App

2011-01-24T18:34:00.001-08:00

If you need to deploy an MVC 3 application to a server that doesn’t have MVC 3 installed in the GAC, it’s pretty easy to do:

1. Add References

Add the following references to your project:

Microsoft.Web.Infrastructure
System.Web.Razor
System.Web.WebPages.Deployment
System.Web.WebPages.Razor

2. Set References to “Copy Local”

Set “Copy Local” to true for the following references:

Microsoft.Web.Infrastructure
System.Web.Helpers
System.Web.Mvc
System.Web.Razor
System.Web.WebPages
System.Web.WebPages.Deployment
System.Web.WebPages.Razor

3. Setup URL Rewriting for Virtual Directories

You only need to do this if you are deploying to a virtual directory. Say you are deploying to the sub-domain “turtles.mrdustpan.com”, which actually corresponds to a “turtles” virtual directory. Without the following URL rewrite, your MVC URLs would look like: turtles.mrdustpan.com/turtles/Home/Index instead of turtles.mrdustpan.com/Home/Index.

To rewrite the URLs, add this to the system.webServer section of your web.config:

<system.webServer>
    <rewrite>
      <rules>
          <rule name="Remove Virtual Directory">
              <match url=".*" />
              <action type="Rewrite" url="{R:0}" />
          </rule>
      </rules>
    </rewrite>
</system.webServer>

My Git Cheat Sheet

2011-01-06T16:38:00.001-08:00

Here’s a nice little cheat sheet of the most common commands I’ve been using in Git, to push my changes out to Github:

cd /c/dev/projects	change directory to c:\dev\projects
git status	get the status of current directory
git add .	stage all pending adds/updates
git add -u	stage all pending updates/deletes
git commit –m "my message"	commit the changes with a message
git push origin master	push the committed changes to github
git branch myBranch	create a new branch named “myBranch”
git branch	list all existing branches
git checkout myBranch	switch to the “myBranch” branch
git checkout master	switch to the “master” branch
git merge myBranch	merge “myBranch” into the current branch

Ninject with ASP.NET MVC 3…Easy As 1, 2, 3

2010-12-14T19:35:00.001-08:00

Add references to Ninject.dll and Ninject.Web.Mvc.dll (You can use NuGet to add Ninject, but for now you’ll have to download and build Ninject.Web.Mvc yourself).

Create 1 or more modules:

public class MyModule : NinjectModule
{
    public override void Load()
    {
        Bind<IFoo>().To<Foo>();
    }
}

Make your HttpApplication (typically global.asax.cs) extend NinjectHttpApplication and override the CreateKernel() method:

public class MvcApplication : NinjectHttpApplication
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new HandleErrorAttribute());
    }

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapRoute(
            "Default",
            "{controller}/{action}/{id}",
            new { controller = "Home", action = "Index", id = UrlParameter.Optional }
        );
    }

    protected override void OnApplicationStarted()
    {
        base.OnApplicationStarted();

        AreaRegistration.RegisterAllAreas();

        RegisterGlobalFilters(GlobalFilters.Filters);
        RegisterRoutes(RouteTable.Routes);
    }

    protected override IKernel CreateKernel()
    {
        return new StandardKernel(new MyModule());
    }
}

That’s it. Now you’re all set to go, even your controllers will be created with Ninject which means all of their dependencies will be resolved using your Module(s).

Setting Up Git

2010-11-18T20:13:00.001-08:00

I’ve never used Git (or any distributed revision control system) before, so I thought this would be a good opportunity to get my hands dirty. I found a few really helpful resources:

Rather than rehash what these resources wonderfully describe in detail, I’ll just summarize the steps I went through to get msysgit up and running and setting up the repository on Github. As I said, I’ve never used Git before and I am certainly no expert, so hopefully I won’t get any of the terms wrong.

Installing msysgit

For this I pretty much followed Jason’s instructions step by step for installing msysgit on Windows:

Download the latest version.
Run through the installation steps.
Run Git Bash from the start menu and set the global user.email and user.name settings:

git config --global user.email my@email.com
git config --global user.name “Your Name”

Generate an SSH key pair:

ssh-keygen –C “my@email.com” –t rsa
Press enter when prompted on file location, and twice more for both pass phrase questions.

Right-click on the folder where the project source will live and select “Git Bash here”.
In the Git Bash console, type: git init

Setting up Github

I want to use Github as the central host for my code. It’s pretty easy to do (Github’s help is also very…helpful):

Create a Github account.
Go to your account settings and click on “SSH Public Keys” and then “Add another public key”.
Open the public key file that was generated above and paste the contents into the Key field.
Create the Atmosphere repository in Github.
Follow the steps on the next page to initialize a local folder as a Git repository.
Create some files.
Create a .gitignore file by typing touch .gitignore
Add ignored folders and files to the .gitignore file (such as obj and bin).
Run git status to see status of changed/added files.
Run git add . to “stage” the files.
Run git commit to commit the changes.
Run git remote add origin git@github.com:MrDustpan/Atmosphere.git to set origin to Github.
Run git push origin master.

And there you have it, the Atmosphere repository is up and running:

https://github.com/MrDustpan/Atmosphere

Hey I’m Gonna Build My Own Blog

2010-11-18T18:51:00.001-08:00

I’ve decided to take on the task of writing my own blog engine. Inspired as I often am by Rob Connery, and filled with a desire to work on some sort of open source project, I figured this would be a good place to start.

Why Would I Do This?

Lots of reasons. Like I said, Mr. Connery told me to. Plus I want to try some new things. I’ve wanted to learn git/github for a while now so I think I’ll put my code out there. Plus I’ve been meaning to use NHibernate in a real project (and blog about it) for a long time.

I’m going to build this using “best practices” so maybe it will be helpful for others too. The reason I have that in quotes is because I’ll be using the best practices I know of, which means there’s a good chance they’re not actually the best. But if everything goes as planned, I’ll learn a lot in the process and maybe have a cool new blog engine that I can call my own.

Features

I want to keep things simple at first, mainly so I’ll actually finish a v1. In the future I’m sure I’ll add some awesome features, like the ability to make me a sandwich. Here’s my list for v1:

Posts
- Ability to add/edit/remove posts
- Ability to tag posts
- Ability to group posts into a series (I really like this idea)
- Ability to remove comments
Comments
- Ability to add comments
- Maybe use markdown?

Time to Get to Work

Well it’s not much, but at this point I have a basic idea of where I want to go. First steps will be to get the plumbing working, and I’ll start with getting source control setup. Only thing I need to do now is come up with a name for my blog engine…how about Atmosphere? Sounds pretty awesome to me.

MSDN Gripe

2010-11-18T12:57:00.001-08:00

As a .NET developer, I often find myself on the MSDN website. This is a great site with a ton of resources, not least of which is the documentation for the .NET framework.

However I notice that when I Google for something I often find myself trying to avoid links to MSDN, instead looking further down the list hoping for a Stack Overflow result. I think this is because it takes me a long time to drill through all of the information to find what I need.

For example, I was looking for some information on LINQ to XML. I have never done anything with LINQ to XML, so I was looking for a couple of samples to get me going. Since I’m pretty familiar with LINQ in general, all I really need are a couple of good code samples to get me started.

Can I Have Teh Codez Plez?

Seriously, I’m a developer – I don’t actually like reading regular people words that much, show me the code.

After being linked to the LINQ to XML page on MSDN from this great SO question, here’s what it took to see some code:

Clicked on “Samples (LINQ to XML)”.
Clicked on “Introduction to LINQ to XML Sample” (since this was the c# sample).
Came to a page with a bunch of words, none of them being actual code. This page rambles on and on about some samples and how to install them.
There is a link that looks promising, I click it. Still no code. Again, it’s talking about some sample library that you can download and install. I’m looking for about 10 lines of code here…fail.
Go to google.com.
Enter “LINQ to XML sample” and search.
Click on the first result.

Don’t get me wrong, MSDN is an invaluable resource for .NET developers, just seems a little hard to find what I’m looking for at times.

WCF Services in ASP.NET Compatibility Mode with ASP.NET Impersonation

2010-06-28T07:38:00.001-07:00

Recently I was trying to setup some WCF services, hosted by IIS, to behave basically the same as ASMX services. I had a difficult time figuring out the impersonation piece - I kept getting accessed denied errors to my database because the process was running under the default ASP.NET account of the machine instead of the user my site was runnning under. I found a couple of good articles (here and here) that helped me along, but this is a more concise description of what you need to get it set up:

IIS Setup

The site (or virtual directory) needs to be setup with Anonymous access enabled and nothing else (e.g. no Integrated Windows authentication).

Web.Config

In your servies web.config file, you need to set aspNetCompatibilityEnabled to true:

<system.serviceModel>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>

Also, since we want to use ASP.NET impersonation (and not WCF impersonation), you need to turn off WCF impersonation for all operations in the behavior configuration:

<behaviors>
    <serviceBehaviors>
        <behavior name="BehaviorConfig">
            <serviceAuthorization impersonateCallerForAllOperations="false" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Service Classes

And finally, each of your service classes (the actual service classes, not the interfaces) need to be marked with the appropriate AspNetCompatibilityRequirements attribute:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]

Testing Validation Attributes in ASP.NET MVC

2010-03-14T19:36:00.001-07:00

Update: Check out the AssertDataAnnotation class by Scott. Removes the ugliness of dealing with strings and helps you adhere to the DRY principal.

One of the really cool features of MVC 2 is the integration of Data Annotation validation attributes with the model binder. You can add pre-defined validation attributes to your view models (or roll your own) and the validation is automatically performed by the magic that is MVC.

Of course you’ll want to do this using TDD, so I thought I’d post a couple of sample tests that show you exactly how.

Verify that an attribute exists on a model property:

[Test]
public void NameHasRequiredAttribute()
{
 // Arrange
 var type = typeof(SongDetailView);
 var methodInfo = type.GetProperty("Name");
 // Act
 var attributeExists = Attribute.IsDefined(methodInfo,
  typeof(RequiredAttribute));
 // Assert
 Assert.IsTrue(attributeExists);
}

Verify that a property of an attribute is set correctly:

[Test]
public void NameHasRequiredAttribute_WithErrorMessage()
{
 // Arrange
 var type = typeof(SongDetailView);
 var methodInfo = type.GetProperty("Name");
 // Act
 var attribute = (RequiredAttribute)Attribute.GetCustomAttribute(
  methodInfo, typeof(RequiredAttribute));
 // Assert
 Assert.AreEqual("Please enter a song name.", attribute.ErrorMessage);
}

The model I’m forced to create:

public class SongDetailView
{
 [Required(ErrorMessage="Please enter a song name.")]
 public string Name { get; set; }
}

TDD Code Snippet for Visual Studio

2010-01-13T11:14:00.001-08:00

Here’s a little code snippet I wrote for Visual Studio. It creates the shell of a Test Driven Development test (or any unit test, I suppose). Here’s how to install it:

Open up your snippets folder. It will most likely be somewhere like this:
C:\Documents and Settings\userName\My Documents\Visual Studio 2008\Code Snippets\Visual C#\My Code Snippets
Create a new text file and rename it to “tdd.snippet”.

Open the file, and paste this inside:

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">

   3:     <CodeSnippet Format="1.0.0">

   4:         <Header>

   5:             <Title>tdd</Title>

   6:             <Shortcut>tdd</Shortcut>

   7:             <Description>Code snippet for creating TDD test shell</Description>

   8:             <Author>Dustin Brown</Author>

   9:             <SnippetTypes>

  10:                 <SnippetType>Expansion</SnippetType>

  11:             </SnippetTypes>

  12:         </Header>

  13:         <Snippet>

  14:             <Code Language="csharp"><![CDATA[[TestMethod]

  15:     public void If_When_Then()

  16:     {

  17:         // Arrange

18:

  19:         // Act

20:

  21:         // Assert

  22:     }]]>

  23:             </Code>

  24:         </Snippet>

  25:     </CodeSnippet>

  26: </CodeSnippets>

Save the file and fire up Visual Studio. You should see the snippet in your Code Snippets Manager (Ctrl+K, Ctrl+B).

Now, when you’re going to write a test, just type “tdd” and hit Tab twice. You’ll see something like this:

   1: [TestMethod]

   2: public void If_When_Then()

   3: {

   4:     // Arrange

5:

   6:     // Act

7:

   8:     // Assert

   9: }

Obviously this works well for me – I’m using MS Test and I like to name my tests using an “If_When_Then” pattern. But if you’re using another testing framework, such as NUnit, or you like you use a different naming convention, just modify the snippet.

Also you could get fancy and add place holders in the method name so you could tab through and enter each part of the method name.

Cheers!

PDC 09 : Days 2 & 3

2009-11-19T15:50:00.001-08:00

The past couple days have been pretty crazy. I didn’t have a chance to blog last night because I was too beat after Geekfest!

Here is some random stuff from the past 2 days:

Keynote day 2:

The Gu gave a great keynote and talked about Silverlight pretty much the entire time. I’m really getting the feeling that this is a big piece the future of web development for Microsoft.
There was a lot of talk about Windows 7 and how awesome it is, and how they really want us to create some butt kicking apps to make it better.
Scott Hanselman gave a little demo of creating a business app with Silverlight, that was cool.
They made the big announcement that all PDC attendees would receive a free tablet PC! I’m actually writing this post on mine now. Super sweet!

Model-View-Ninja!

After the keynote I went to Hanselman’s session on asp.net mvc 2. It was titled something like “Super awesome ninjas on fire and mvc 2” or something. It was really good, probably my favorite session at the conference. He was super funny and informative, as always.
I attended another session by Stephen Walther on MVC 2 where he covered all of the new stuff. A lot of cool enhancements that I really like.

Geekfest

After the day was over they had Geekfest! A big party with games, beer, food and pumping music. It was fun, but only 2 hours long :(
My coworker and I ended the evening by playing a little Halo on the 360 machines they had setup.

Takeaways

Here’s a list of stuff that I heard a lot about, and I want to learn much more:
- Azure
- Silverlight
- RIA Services
- MVC 2

PDC this year was a blast. Tons of content, more than I could take in. I’ll be hitting the PDC site to download sessions that I missed and I’ll be digging into some of the labs I didn’t have a chance to get through. It was a crazy 3 days, but loads of fun!

PDC 09 : Day 1

2009-11-17T22:31:00.001-08:00

Wow, I’m beat. Just got back to the hotel after a full day at the convention. Here are some highlights:

It’s All About the Cloud

This morning’s keynote focused almost entirely on the Windows Azure stack. It seems clear that Microsoft is very serious about Azure and it sounds like it will be a big part of their technology in the future. Ray Ozzie talked about the “3 Screens & a Cloud” a lot. Basically the idea that your mobile device, your pc, and your TV should all seamlessly work together using apps hosted in the cloud.

There was also a lot of emphasis on Silverlight. Up to this point my exposure to Silverlight has been pretty limited, but I think I’d like to explore that more. I’m especially intrigued by the idea of Silverlight + ASP.NET MVC.

After the keynote I attended the “Lap Around Azure” session. It was pretty informative and had a couple of demos (which I always like – show me the code!). I think I’m really going to need to dig into this myself. If only there were hands on labs here…

Hand on Labs

So after the Azure session, it was lunch time (awesome food btw). After I scarfed down my food I figured I would hit the Azure labs because I wanted to get some real experience and learn something. When I got to the labs there was a line of about 200 people waiting to get into the Azure labs. Oh yeah, there was also some flip camcorder giveaway for people that would attend an Azure session and then do a lab.

So I abandoned that idea and decided to check out the web platform labs. On my way there I strolled by the Channel 9 live broadcast and it was Scott Hanselman interviewing the guy who runs failblog.org!! I sat and watch that for a few minutes, Scott was super funny as usual. I was a little star struck – Hanselman is totally my hero…well one of my heroes anyway.

I then hit the ASP.NET labs and started one that was ASP MVC 2, Ajax and Entity Framework. The lab was awesome but I didn’t finish it. The VM I was working on was really sluggish and there was a lot of code to write!

BDD & TDD

After that I went to a Birds of a Feather session on BDD (Behavior Driven Design) and TDD (Test Driven Development). These BOF sessions are meant to be a discussion where the attendees are involved. This is near and dear to my heart because I’m a TDD fan boy.

There were a lot of people there that didn’t really know what TDD was, and even more (myself included) that didn’t know much about BDD. It was a very lively and entertaining discussion.

Partner Expo

After that was the partner expo. Lots of good food and drink, saw Scott Hanselman get out-coded by a dude with Rock Band guitar (I know it was the crappy keyboard!), and talked to a bunch of cool vendors.

I signed up for a trial with Safari Books Online which I’m super pumped about. They even gave me a free book which was sweet. Also got a couple of t-shirts and other swag, and had a really good time.

Can’t wait for tomorrow!

SQL Change Data Capture __$operation Values

2009-10-19T10:17:00.000-07:00

In case you want to know what the value of the __$operation field means in a SQL CDC table, here ya go:

1 = delete

2 = insert

3 = update (before the update)

4 = update (after the update)

Linq to SQL – Roll Your Own Domain Model

2009-10-01T19:45:00.001-07:00

When using Linq to SQL in Visual Studio, there is a really nifty designer interface. It allows you to drag tables (and views, stored procedures, etc.) from a database onto the designer surface. Behind the scenes a domain model class is created. Using the DataContext, you can persist data to, and retrieve data from, the database using these strongly typed domain objects.

This offers several advantages:

Easy to use – just drag your tables onto the designer.
The DataContext handles many “infrastructure” tasks for you: transactions, concurrency checking, parameterized SQL, etc.
Strongly typed objects that are partial classes - they can be extended to add your business logic.
A nice visual representation of your domain in the designer.

However, there are a few big disadvantages:

Your domain models are tightly coupled to your ORM technology (Linq to SQL).
Any other layer of your application that wants to have access to your domain models would have to reference the project that contains your data access.
Unless you plan to modify (and maintain) the models that are auto-generated, your database schema has to mirror your domain model.

There is an approach that we can take that will alleviate most of the disadvantages while still offering us the benefits.

I’ll Create My Own Models, Thank You Very Much

What we can do is create our own models and map them (yes, using xml) to the correct database table. This removes the mapping from our domain models and allows us to put them in a totally different assembly if we want.

Let’s pretend like we know how to do Domain Driven Design, and design a super useful application about dogs. We’ll say we’ve come up with the following nouns and verbs about a dog:

Nouns
- Breed
- Name
- Weight

Verbs
- Bark

Like I said, super useful. So here’s what that might look like translated into code:

The Model:

   1: namespace Core.Models

   2: {

   3:     public class Dog

   4:     {

   5:         public int Id { get; set; }

   6:         public string Breed { get; set; }

   7:         public string Name { get; set; }

   8:         public int Weight { get; set; }

9:

  10:         public void Bark()

  11:         {

  12:             // Do some barking

  13:         }

  14:     }

  15: }

the Mapping XML:

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <Database Name="DogDb" xmlns="http://schemas.microsoft.com/linqtosql/mapping/2007">

   3:     <Table Name="Dog">

   4:         <Type Name="Core.Models.Dog">

   5:             <Column Member="Id"

   6:                 Name="Id"

   7:                 AutoSync="OnInsert"

   8:                 IsPrimaryKey="true"

   9:                 IsDbGenerated="true"

  10:                 DbType="Int NOT NULL IDENTITY"/>

  11:             <Column Member="Breed" Name="Breed" DbType="VarChar(50) NOT NULL"/>

  12:             <Column Member="Name" Name="Name" DbType="VarChar(50) NOT NULL"/>

  13:             <Column Member="Weight" Name="Weight" DbType="Int NOT NULL"/>

  14:         </Type>

  15:     </Table>

  16: </Database>

and the Repository:

   1: namespace Infrastructure

   2: {

   3:     public class DogRepository : IDogRepository

   4:     {

   5:         private DataContext _db;

6:

   7:         public DogRepository()

   8:         {

   9:             XmlMappingSource map = XmlMappingSource.FromXml(File.ReadAllText("DogMap.xml"));

  10:             _db = new DataContext("ConnectionString", map);

  11:         }

12:

  13:         public Dog Fetch(int dogId)

  14:         {

  15:             return _db.GetTable<Dog>().SingleOrDefault(x => x.Id == dogId);

  16:         }

17:

  18:         public void Add(Dog dog)

  19:         {

  20:             _db.GetTable<Dog>().InsertOnSubmit(dog);

  21:         }

22:

  23:         public void Delete(Dog dog)

  24:         {

  25:             _db.GetTable<Dog>().DeleteOnSubmit(dog);

  26:         }

27:

  28:         public void SubmitChanges()

  29:         {

  30:             _db.SubmitChanges();

  31:         }

  32:     }

  33: }

Pretty simple and elegant. Not perfect though. Yes XML sucks, and yes the repository is still tightly coupled to Linq to SQL, but at least with this approach our model isn’t cluttered with ORM specific attributes.

TDD Part 4: Conclusion

2009-07-23T13:54:00.003-07:00

Well I hope you’ve enjoyed this series. Again, I wasn’t aiming to answer every question around TDD, as I still have many myself. But rather I wanted to share my experiences in hopes that it might help someone else.

Also, I would really love some feedback on all this, so if you have questions or comments please let me know!

TDD Part 3, Key #3: Using Fakes and Dependency Injection

2009-07-23T13:54:00.001-07:00

Introduction
Part 1: Why use it?
Part 2: Write My Tests First?
Part 3: Keys to Effective TDD
Part 3, Key #1: Write Testable Code
Part 3, Key #2: Write Good Tests
Part 3, Key #3: Using Fakes and Dependency Injection
Part 4: Conclusion

As mentioned earlier, we need to be able to use Dependency Injection so we aren’t testing more than one thing. And if we don’t want to test more than one thing, that means we’ll have to “inject” same fake objects.

Using Fakes (or Mocks as many people refer to them) was one of those things that took me a while to understand.

When I first started TDD, I would create my own “mock” classes, like a mock repository that would return real data. In the mock class, I would essentially build up an in-memory database that I could then query and return data from. Needless to say, that was a huge pain and was not maintainable.

Then I started reading about mocking frameworks. But still I didn’t get it. “They don’t do anything, what’s the point?” But that is the point, we don’t want them to do anything. They are just there to either allow our code to run, or so we can verify that they were utilized correctly.

Here is a sample test checks to see if our PrintInvoice() method calls the repository like it should (using Moq as the mocking framework):

This might seem a little crazy so let’s break it down.

First of all, notice the Arrange, Act and Assert sections. I like to put this in each of my tests to remind me that my test has 3 parts. First, setup the test scenario. Then perform some action – this is what we’re actually testing. Finally, verify that what we expected to happen actually happened.
In the Arrange section, I’m setting up four Fake objects. These will be passed into the InvoicePrinter constructor so we can perform our tests. Keep in mind, these objects are fake and don’t really do anything, they’re just there so we can run our test and verify that it worked.
The Assert line might be a bit confusing – it was for me at first. But really it’s saying “verify that my mock repository object had it’s FetchOrder() method called exactly once, and that the value passed into it was 1234.”

Fakes, Mocks, & Stubs?!?

As Martin Fowler put it, mocks aren’t stubs! So what are mocks, stubs, and fakes – and what difference does it make? Here’s a short explanation of each:

Fake == a generic term for Mocks & Stubs
Mock == a Fake that is used to verify something
Stub == a Fake that is just a place holder so your code can run

So in the example above, the repository object was a Mock. That’s because we verified that some certain behavior on that object was invoked. The other Fakes in that method are all Stubs – they’re just there so our test can run.

IoC Containers

Let’s say we have this class:

As you can see we are using Dependency Injection for our ILogger. This allows us to test just our SalesTaxCalculator class without worrying about the concrete implementation of ILogger.

But what about our “real” code? At some point we need to create a concrete implementation of the ILogger interface and get it into our class, right?

There are a couple of ways we could do this. We could have another constructor that doesn’t take any arguments and defaults _logger to our real Logger class. But that’s a little smelly – we are technically still coupled to that Logger class in some way.

Another way to do it is to use an Inversion of Control Container (IoC Container). These are utilities that allow you configure what the default implementation of a given interface is. Then, when that interface is required, the IoC container will give you an instance of the default.

For example, here is what a Castle Windsor configuration might look like for our ILogger interface:

This tells Castle: “Anytime I’m looking for an ILogger, give me a Logger. By the way, ILogger and Logger are both in MyApp.dll under the MyApp namespace.”

So if we are configured to use IoC, we don’t have to change our SalesTaxCalculator class at all. The IoC container will just give us the correct concrete class any time we need one.

Simone Busoli has an awesome four part article on using Castle Windsor.

TDD Part 3, Key #2: Write Good Tests

2009-07-23T13:53:00.001-07:00

Introduction
Part 1: Why use it?
Part 2: Write My Tests First?
Part 3: Keys to Effective TDD
Part 3, Key #1: Write Testable Code
Part 3, Key #2: Write Good Tests
Part 3, Key #3: Using Fakes and Dependency Injection
Part 4: Conclusion

This is an obvious one, but what does it mean to write “good” tests? There is a great Hanselminutes podcast with Roy Osherove that gives you an idea of what makes good tests.

Your Tests Should Be Readable

Your tests are code too, and just like all of your other code you want it to be nice and readable. This means naming your classes, functions and variables with meaning!

InvoicePrinterTests is a good name for a class that tests the InvoicePrinter class. TestClass1 is not.

PrintInvoice_Calls_Repository_FetchOrder() is a good name for a test that verifies that the OrderRepository.FetchOrder() method is called when we call PrintInvoice(). Test1() is not.

I like to name my test functions so they read like English, and if you were to replace the underscores with spaces, you’d have a pretty understandable statement (“PrintInvoice calls repository FetchOrder”). If you don’t like underscores, that’s fine – just choose a convention that helps you describe exactly what the function is testing.

Your Tests Should Be Maintainable

Just like with “regular” code, we want our tests to be maintainable. This means your test functions should probably be no more than 10-15 lines in length.

And another thing I’ve discovered: if you run into a situation where you’re finding it hard to test something, or your test is just getting big and complicated – you almost certainly need to refactor something. I’ve run into this many times and every time I found that it was because the code I was trying to test was too complicated and needed to be split up and tested separately.

Your Tests Should Test Only One Thing

Each test function should test one, and only one, thing. A good check (although this isn’t always true) is to see whether you have more than one Assert statement. If so, there’s a good chance that you are testing more than one thing.

Your Tests Should Be Trustworthy

In order for tests to have long lasting value, you have to trust them. If you’re not confident in your tests, then you can’t be confident in the results they produce. If, on the other hand, you are totally confident in your tests, when they fail you can be sure that there is a bug in your code that needs to get squashed.

How do you make “trustworthy” tests? If you follow the 3 guidelines above, you’ll be well upon your way.

TDD Part 3, Key #1: Write Testable Code

2009-07-23T13:52:00.001-07:00

Introduction
Part 1: Why use it?
Part 2: Write My Tests First?
Part 3: Keys to Effective TDD
Part 3, Key #1: Write Testable Code
Part 3, Key #2: Write Good Tests
Part 3, Key #3: Using Fakes and Dependency Injection
Part 4: Conclusion

So if you want to test your code, you need to write that code can be tested. Wow, astounding. That’s like saying if you want to score a touchdown you need to get the football in the end zone.

Well, put another way – you need to structure your code in such a way that makes it easier to test. So what does that mean? A few things:

Separation of Concerns

In order to have an effective unit test, you need to be testing only one thing. That means your code needs to be written so each of the “concerns” are isolated into small, testable chunks. Which brings us to our next point:
Single Responsibility

This is really an extension of the previous point, but to achieve separation of concerns a good approach is the Single Responsibility Principle (pdf). This states that a class should have one, and only one, reason to change. In other words a class should do only one thing (and do it well!) This means that your ShippingCalculator class shouldn’t calculate shipping and write logging information to a text file. It should call out to a separate Logger class to do that.
Inversion of Control

Ok, so I’ve separated my concerns into single responsibilities, that’s cool. But now if I want to test my CalculateShipping() method, it will end up calling my Logger class too. Doesn’t that mean I’m really testing more than one thing, which is not what I want to do? Exactly.

So, instead of calling our real Logger class, it would be nice if (during our testing) we called a “fake” class that didn’t do anything. Enter Inversion of Control (IoC) and “Fakes”.

IoC means that instead of a class being responsible for creating the other classes it depends upon, these are provided to it (thus “inverting” the control). This allows us to inject our dependencies into our classes which will allow us to use a “fake” logger when our tests run, and the “real” logger in the production code. (Another common term for IoC is Dependency Injection.)

Let’s take a look at a couple samples.

Class 1: Not very “testable”:

Here are the problems that I see with this class:

Concerns are not separated. This method is calculating sales tax, logging to a file, and printing and invoice. It’s hard to test only one thing when our method is doing three things.
This function is performing disk IO and, presumably, connecting to a real database through the OrderRepository class. This can cause our tests to be brittle and slow. Not good!

Let’s take a look at a more testable version:

Class 2: Now that’s what I call testable!

What’s so great about this class? Well, none of the problems identified above are there anymore. We can write tests that will only test this specific function of this class.

Now you might be noticing that this function doesn’t really do anything. That’s right! It’s really more of an aggregator that combines the functionality of other classes to perform some operation.

So how would you test this method? Well I would probably have 4 tests:

Verify that the FetchOrder() method on my IOrderRepository gets called.
Verify that the Calculate() method on my ISalesTaxCalculator gets called.
Verify that the Log() method on my ILogger gets called.
Verify that the Print() method on my IPrinter gets called.

That’s it. We’re testing what this function does, which is call other functions. So, assuming that we have other tests that will test each of those other functions, this PrintInvoice() method is totally covered by unit tests.

TDD Part 3: Keys to Effective TDD

2009-07-23T13:51:00.003-07:00

Introduction
Part 1: Why use it?
Part 2: Write My Tests First?
Part 3: Keys to Effective TDD
Part 3, Key #1: Write Testable Code
Part 3, Key #2: Write Good Tests
Part 3, Key #3: Using Fakes and Dependency Injection
Part 4: Conclusion

When I first started using TDD, it was a struggle. My tests seemed as complicated as the actual classes I was trying to write, and I didn’t really feel like I was getting a lot of benefit from the tests.

When I would change some code that would cause a test to fail, I didn’t really have confidence in the test. So instead of fixing the code, or refactoring the test to meet the new functionality, I would sometimes end up just commenting out the test itself.

Not very useful.

Not to mention maintaining all of my “mock” classes, such as repositories, that would contain enough data and functionality to make my tests useful. It was a headache and found myself nearly giving up on the practice.

But over time, I realized a few key items that helped make TDD more effective.

Write Testable Code
Write Good Tests
Use Fakes and Dependency Injection

I’ll expand on these three points in my next three posts.

TDD Part 2: Write My Tests First?

2009-07-23T13:51:00.001-07:00

Introduction
Part 1: Why use it?
Part 2: Write My Tests First?
Part 3: Keys to Effective TDD
Part 3, Key #1: Write Testable Code
Part 3, Key #2: Write Good Tests
Part 3, Key #3: Using Fakes and Dependency Injection
Part 4: Conclusion

When I first read about TDD (many years ago), one of the first things I saw was: write your tests first.

“What?

This is stupid, I’m gonna go get a sandwich.”

That idea didn’t make sense to me, and I think that’s probably the reaction most developers who don’t use TDD would have.

How can you test something that doesn’t exist? Well, you can’t. But the idea, as mentioned in the previous post, is that this isn’t just about testing. It’s really about design.

“Ok, so I write all my tests and then write my code? How am I supposed to do that. I still don’t get it.”

That was a big misunderstanding of mine. You don’t write all of your tests up front, you write them one at a time and then write the code to satisfy those tests – one at a time. You start small and your tests force you to slowly create your classes and functions. Eventually, where there was a blank screen, now you have a bunch of functional code that is covered by tests.

The Red, Green, Refactor Show
The “test-first” approach basically has 3 steps:

Red – Write a test and make sure it fails. It’s called the “Red” step because most unit testing tools will display a red failure message. Failure is good at this point. We love failure.
Green – Write the minimum amount of code to make your test pass. And yes, the unit testing tools will display a nice lovely green message. Ah, green…success, peacefulness.
Refactor – You have some code that passes a test, way to go. But guess what? That code sucks. Refactor that code so it is nice and pretty. This step doesn’t have to occur after each test is written. You might want to wait until you have a few methods, maybe even an entire module, done before you refactor it.

Where Do I Start?
Let’s see this in action with an example. Let’s say the first thing we want to do is write this “calculate shipping module”. We don’t know if it will be 1 method, or 10, or 100. But the tests will guide us.

All right, what’s the first requirement?

Shipping = Order quantity * 3

What do we know? Well from that requirement I’d say we need a method that accepts order quantity as a parameter and returns that number multiplied by 3. Pretty easy, so let’s write our first test!

So with these 3 small lines of code, we are essentially creating the following truths:

We have a class called ShippingCalculator.
This class has a method Calculate(), that accepts an integer parameter.
The Calculate() method will return the input parameter multiplied by 3.

Now that’s pretty cool! Of course, these aren’t exactly truths yet since this code won’t even compile (as evidenced by the red squiggly line!) But that’s the way we want it, we are in the red portion of red/green/refactor. And the first “red” test is the compile failure. So, let’s write enough code to make it compile:

There, now it compiles. However this is obviously not going to pass since we are actually throwing an exception in our method. But again, or goal here is to execute a test that fails first. Then we’ll make our method work. Just to be sure…

Yep, it fails – good. Now let’s write the minimum amount of code to make it pass:

And re-run our test:

Awesome! Now we have a class that satisfies our first requirement. We can move onto the next requirements by writing more tests and then implementing the code to make them pass. Eventually we’ll get to a point where we’re ready to refactor this code, which is the final part of red/green/refactor.

At that point, our Calculate() method will be completely covered by tests so we can refactor without fear! We know that if we break anything by accident (who me?) the test will slap us upside the head.

TDD Part 1: Why Use It?

2009-07-23T13:49:00.001-07:00

Anytime you are going try something new, there should be a reason, right? You wouldn’t just go out and spend your hard earned money on a can of New Coke unless you thought it was going to enhance your soft drink refreshment experience. You have an expectation that the taste could be better, so you try it. Maybe not a great example since New Coke didn’t work out so well, but you get the idea.

So that begs the question: Why use TDD?

I’m sure you could find millions of reasons why you should (or shouldn’t) use TDD out there. But for me, it comes down to three main points:

To drive the design of your application.
So you write better code.
So your code is “covered”.

Wow that sounds good. Tell me more.

TDD – It’s Not Just About Testing
This was one of those “huh?” things the first time I heard it. TDD is as much (if not more) about design as it is about testing. The idea is that you write your tests first and then write just enough code to satisfy the test (more on this in the next post).

Now this was a little tricky for us because we are not an agile shop. We’re more of a waterfall kinda place. But TDD can still work well even in when using a waterfall methodology. The key is to not design every tiny detail before you begin coding, but instead to define the basic structure.

Using our sample described in the introduction, let’s look at a couple of different ways we could write a design for a method that calculates shipping:

You could do it like this:

InvoiceManager.CalculateShipping():

Receives an OrderDetails parameter.

Returns a decimal.

Shipping = OrderDetails.Products.Count * 3

If OrderDetails.OrderTotal > 100, Shipping is Shipping *.9.

If Shipping > 30, Shipping is 30.

Or like this:

Calculating Shipping:

Create a module that will calculate and return the shipping for an order:
- Order quantity * 3
- If order total > 100, reduce shipping by 10%
- Maximum amount for shipping is 30

Now although these are very similar, and basically define the same thing (we need to calculate shipping for an order) the first one is much more restrictive, much more dictator-like:

You must create a class called InvoiceManager!
You must create an OrderDetails object, and this object will have an OrderTotal and a Products collection – do you understand??
If you do not create a CalculateShipping() method that takes in an OrderDetails and returns a decimal, you will be promptly shot!

The second approach leaves you a little bit of room. What if you write your CalculateShipping() method and you <gasp> change your mind? You want to take in the order total and order quantity instead of an entire OrderDetails object? What if you decide you don’t want to name your class InvoiceManager because you realize it’s a stupid name? You have some room to move with regard to the design of the code, but the end result will be the same: something that correctly calculates shipping.

Now when you’re writing your tests, you can flush out these details as they are needed. It will help you avoid over-engineering something right from the start. And it will most likely result in cleaner, less complex code.

Write Better Code
In my experience, using TDD helps my code turn out better in a few ways:

No Extraneous Code – using the “only-write-the-minimum-code-required” principle, you don’t end up with extra stuff. All code you write is there because there was a failing test that forced you to write it.
Smaller, Simpler Objects – I’ve found that in order to test something, it needs to be simple to test. This naturally drove me to writing smaller objects that were less complex and basically did only 1 thing (SRP, anyone?).
Separation of Concerns – Similar to the previous point, in order to easily test something you need to have good separation of concerns so you are only testing 1 thing. More on this in a future post.

Don’t Worry, You’re Covered
Warm and fuzzy. That’s how well written unit tests can make you feel. You know that your code is solid and, more importantly, that it can be modified without fear. If you have tests that verify all of the required functionality for some module, you can refactor, modify, extend or otherwise mess with that module – and you know you’re covered. If you break some existing functionality, your tests will smack you in the face. It’s a wonderful thing.

Test Driven Development: Introduction

2009-07-23T13:42:00.001-07:00

Recently another developer and I have had the privilege of working on a green field project - something that we developers don’t always get a chance to do. It has been fun, exciting, daunting, frustrating – and above all else, educational.

One thing that we wanted to try on this project, which we really haven’t done in the past, is unit testing (crazy, huh?). And I had read about some idea that a bunch of weirdos came up with called “Test Driven Development” that sounded intriguing.

So we decided what the heck, let’s TDD this puppy and see what happens. Of course we didn’t really know anything about TDD, or unit testing in general for that matter. But with everyone raving about its awesomeness we figured it would just come to us in a zen-like moment of clarity while hacking away at our code. Needless to say we ran into some bumps along the way, and there were times when we were left scratching our heads saying “I still don’t get it.” But we learned and failed, and failed and learned, and I feel like we’ve come out the other end of the tunnel with a better understanding of the how’s and why’s of TDD.

This is the first in what is going to be a series on my experiences and understanding of the TDD process. I am by no means an expert – I still consider myself a novice at this. However I do feel that I have learned a ton in the past 7 or 8 months, and I think it could be helpful to others. Especially those wondering why TDD, and how to get started.

The Sample
For all of these posts on TDD, we’re going to need a sample. So using my great genius I came up with this fake requirements spec:

“Print Invoice” Screen Requirements

Create a “Print Invoice” screen. When a user enters an order number and clicks the print button, the invoice for that order will be printed.

The invoice should contain:

Customer Information (customer number, name, shipping address…)

Order Details (product and quantity information)

Shipping Costs

Sales Tax

Invoice Total

Calculating Shipping:

Standard shipping is $3.00 per item.

If the order total exceeds $100 there is a 10% discount on shipping.

There is a maximum shipping charge of $30.

Calculating Sales Tax:

Sales tax is 7% of the order total.

Now we’re ready to get going.

More WCF Goodies

2009-02-12T06:54:00.001-08:00

This blog post wonderfully explains this issue in detail, but here’s another FMI post:

Trying to add a custom endpoint or service behavior to a WCF service? Be sure that your custom behavior extension in the config file is exactly 100% perfectly correct. The <add /> element of the behaviorExtension needs to have it’s “type” attribute exactly match your type.

For example, this entry:

Is not the same as (notice the lack of spaces):

So everything, from spaces to version number have to match character for character, or else you’ll get this exception:

An error occurred creating the configuration section handler for system.serviceModel/behaviors: Extension element '...' cannot be added to this element. Verify that the extension is registered in the extension collection at system.serviceModel/extensions/behaviorExtensions.

ASP.NET MVC, jQuery Ajax, FireFox and IIS 6 Combine for a 411 Length Required Error

2008-12-04T06:19:00.001-08:00

(What a stimulating title) Here's a fun nugget I recently discovered when deploying our ASP.NET MVC application to our dev server. We have a very simple editor that allows you to do basic CRUD operations, that (of course) worked great on my box. When I deployed it, however, I couldn’t perform a delete when using FireFox. Worked fine in IE and worked fine in both browsers when running on my machine, using the built in VS web server.

I opened up FireBug and looked at the response from the server. It was sending back "<h1>411 Length Required</h1>". Weird. My view was using jQuery Ajax to send the Id of the item to be deleted to my controller – it basically looked like this:

function DeleteItem()
{
    if(confirm("Are you sure you want to delete this Item?"))
    {
        $.post("/Item/Delete/" + $("#ItemId").val(),null,function(data){
            document.location = "/Item/";
        },"json");
    }
}

So essentially it would post to "/Item/Delete/2" to delete the item with an Id of 2.

After searching around a bit, I found this post and realized that I need to send something for the data parameter. After changing the second parameter in my $.post() call from null to {}, it worked like a charm. Here’s what the post call looks like:

$.post("/Item/Delete/" + $("#ItemId").val(),{},function(data){
    document.location = "/Item/";
},"json");

The contract name 'IContract' could not be found in the list...

2008-12-02T10:20:00.001-08:00

This is really a "note to self" as I've run into this twice now, and I've had to figure it out twice.

When trying to add a new WCF service, you might encounter this error:

The contract name 'IMyService' could not be found in the list of contracts implemented by the service 'MyService'

If you are certain that your service does in fact implement the interface, make sure that your service interface is decorated with the ServiceContract and OperationContract attributes.

This has happened to me because I’m developing my services using TDD, so I don’t need the attributes on my interface when running my tests. But when it comes time to actually implement the service, they need to be there. I guess I should write some tests that verify that my interface has the correct attributes.

Here’s a sample WCF service interface, for reference:

using System;
using System.ServiceModel;

namespace MyCompany.MyApp
{
    [ServiceContract(Namespace = "ServiceNamespace")]
    public interface IMyService
    {
        [OperationContract]
        void DoSomeStuff(string parm1);

        [OperationContract]
        bool StuffWasDone();
    }
}

Posting Complex Types to an ASP.NET MVC Controller using Ajax and jQuery

2008-11-14T19:27:00.001-08:00

One of the many awesome features in the ASP.NET MVC framework is the built-in model binder support for complex types. ScottGu has a good explanation of this in his post about the beta version of ASP.NET MVC. Basically the MVC framework will magically map form post fields to properties on a complex type in a controller method. So, instead of your controller method looking like this:

public ActionResult Save(int id, string name, string price)
{
    ...
}

It can look like this:

public ActionResult Save(Widget widget)
{
    ...
}

Introducing Ajax into the Mix

So I thought it would be cool to have a form that posted to a controller via Ajax, and was able to take advantage of this built-in model binder support. I was very happy to learn that the ASP.NET MVC framework can also map JSON objects to my complex types.

Combining this with a little jQuery goodness and you’ve got a pretty easy way to pass complex types from a View to a Controller using Ajax and jQuery. Let’s look at some code.

Here we have the all important Widget that we will be viewing and saving:

public class Widget
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}

And this is the main code in my controller class:

public ActionResult Widget()
{
    ViewData.Model = GetWidget();
    return View();
}

public JsonResult SaveWidget(Widget widget)
{
    // This is where you'd actually save the Widget
    return Json(new { Result = String.Format("Saved widget: '{0}' for ${1}", widget.Name, widget.Price) });
}

The first method, Widget(), is the view method for the “Widget” action. This is where you’d get the model’s data and bind it to the view.

The second method, SaveWidget(), is where the actual saving would take place. Notice how the return type of this method is JsonResult instead of ActionResult. Also, notice how the method takes in a complex Widget as an input parameter.

And finally, here’s the pertinent HTML and JavaScript for the view:

<form id="Form1">
    <input type="hidden" name="widget.Id" value="1" />
    <input type="text" name="widget.Name" value="my widget" />
    <input type="text" name="widget.Price" value="5.43" />
    <input type="button" value="Save" onclick="SaveWidget()" />
</form>

function SaveWidget()
{
    var formData = $("#Form1").serializeArray();
    
    $.post("/Home/SaveWidget",
    formData,
    function(data){
        alert(data.Result);
    }, "json");
}

Here I’m using the serializeArray() jQuery method to serialize my form data as a JSON object.

This is pretty simple, and powerful. I’m able to post a version of my complex type from the view to the controller using Ajax. And one of the best parts is that I don’t have to write a JavaScript version of my type, or a custom serializer to form up the JSON.

Of course, this poses a few questions as far as validation and formatting are concerned. For example, if you post “$5.43” as the Price property (which is a decimal), it will get changed to 0.00 by the MVC framework. I’ll probably try to figure out a clean way to handle that and I’ll post on it in the future.