I’ll admit it, I’m behind the times. I’ve been a web developer since the late 90’s and a .NET programmer since the first release, but I’m only now really able to check out ASP.MVC, Behavior Driven Design, Unit Testing, patterns, etc. Don’t get me wrong, I’ve been keeping tabs on everything, but actually being able to put them into practice is another.
First things first. I need to choose the individual components of my new development stack and rather frustratingly I have not found 2 people that use the same stack of tools. Which makes this is one of the hardest elements of the project since I need to make informed decisions that will have a huge impact later, without knowing much about what I’m picking. But you have to start somewhere.
Early on when Xtreme Programming was still a buzz word, I got excited and really wanted to embrace Unit Testing. I opened up a project and wrote a few tests. I had a hell of a time dealing with testing database calls, and it was all but impossible to test my logic, which was of course mixed into the codebehind. Like so many others, I quickly gave up and went back to seat-of-your-pants development (SOYPD).
Unit testing evolved over time and it became possible with the use of tools and patterns to organized and test code that made database calls and to make code even more testable. By that point, though it all seemed very foreign rather tedious to implement.
So then came Behavior Driven Design. I was recently at the St. Louis Day of .NET conference and attended back to back sessions that dealt with testing. The first was a traditional unit testing session that had a demo where the speaker made something like 2 or 3 interfaces just to test a simple close button that called Window.Close(). It felt more like OCD, than a practical way of development.
The second session was on Behavior Driven Development with Lee Brandt, or as it is often said, Unit Testing Done Right. It was very eye opening and it clicked with me. Instead of bottom up testing to get 100% coverage, you do top down testing where actually requirements drive what tests you write and by extension, what code you write. It seemed so much more natural and productive, so I started there.
It’s hot and it’s test friendly, not to mention an html lovers dream. Even though it’s been my bread and butter for the past 7-8 years, I’ve been fighting WebForms every step of the way, so this will be a nice departure.
This was a late edition, but after seeing some code samples side by side, it seems like a much more natural way of writing Views than the current gator “tag soup”. It feels a bit risky getting away from the base ASP.MVC product, but everyone that has tried it loves it, so I’m going to give it a shot.
This one is more of a selfish choice for me. I want to learn NHibernate to see what the fuss is about and broaden my skillset. Previously I’ve used LLBLGen Pro quite extensively, and more recently Subsonic 2. I’ve only done a little bit with it, but NHibernate seems somewhere in the middle. Not quite as focused and powerful as LLBLGen Pro, but not quite as easy to use as Subsonic. I’m going to focus on using Nhibernate.Linq as much as possible, since it has quickly become the common language for all major ORM’s.
Besides non-typesafe ICriteria parameters, XML configuration has to be the least unappealing aspect of NHibernate for me. Fluent NHibernate takes that pain away. I still have to write map files, which is tedious compared with LLBLGen Pro and Subsonic, but at least FNH makes it easy enough.
The one downside to FH is the large number of dependencies, something like 5 additional assemblies are needed. I hope they can clean that up in a future release.
It helps to have a specification testing framework when doing BDD, so I went with what is grabbing the most attention. The syntax is a bit goofy, but it makes for clean tests (specs!) and it outputs friendly reports.
This was a rather arbitrary decision, it was the one I had installed on my machine. MSpec still needs a background unit testing framework to make everything flow, but it works just about everything out there.
I also considered Castle Windsor and Ninject for Dependency Injection, but StructureMap seems have a few more tutorials written that involve MVC.
Mocking framework. I chose this over Moq, just because more of the people I know seem to use it.
Miscellaneous
There are a number of other little things I’m including in the project like MCVContrib, which is needed for a couple of the other items above. I may check out log4net or ELMAH later for rich error logging, but that’s something to consider a little later. Of course for my js needs, I’ll be leveraging my old friend jQuery.
So that’s where I’m at today. Tomorrow something may and probably will change, but you have to start somewhere and this is where I ended up.
If you have any comments, questions, or just want to tell me how stupid I am, please leave them below.
In part 2, I will beat myself about the head with architectural decisions, some of which may be derived from my questions on Stack Overflow, here and here.