Current Progress and The Epiphany

By Ryan at December 03, 2009 11:09
Filed Under: Development

It's been about two and a half weeks since my last post.  My project is coming along nicely; I've written a total of about 100 lines of code.  I've spent at least an hour, every day, working on some aspect of the site.  I guess my point is to illustrate how much planning needs to occur before you even write a single line of code.

I think of every application as the creation of building blocks for my next application.  Given this, I tend to labor over the details to ensure that I'm creating a solid framework and not just a one-off web site. While I'd agree with anyone that labeled me as neurotic or obsessive-compulsive, I think this kind of mentality bodes well for a programmer.  

I see programming as a craft, and, as such, I'm always looking for ways to better myself.  In an effort to "future-proof" my design, I'm forced to bring in new technologies and push myself out of my comfort zone (though I'm never really comfortable stagnating.)


One example of this is my epiphany with regards to test-driven development (TDD) (or behavior-driven development.)  See, I find myself stuck in traffic for at least an hour every night.  During this time, my radio is either off or playing a programming-related podcast.  As of late, I've listened to all my podcasts, so it's just me, the road, and my thoughts (and thousands of other motorists).

So, as I'm working through a particular aspect of the framework of my application in my head, it suddenly clicks: this is a perfect place for TDD.  You see, my mind kept wanting to traverse the tree of functionality all the way to the leaf nodes, but right now I only really need to set the stage/build the trunk for those nodes.  I was spending all of my brain power trying to decide how to flesh out the entire design, when I had a solid starting point that could/should be the focus right now.

When following the single-responsibility and open-closed principles TDD is just a perfect fit.  You can create your "trunk" and then mock out all of the nodes.  You create the nodes later and test them independently.  Suddenly, it all made sense.

You see, prior to now, my development workflow was never compatible with the TDD workflow.  I was always trying to make sure I had all my nodes in good order, then put the trunk together (or some amalgamation of that.)  While I've always fully embraced unit testing, I never bought into the test-first pattern.  But, it occurred to me, that it's not "test-first" its more "behavior-first" or "foundation-first."

This epiphany would have never struck me if I hadn't spent the last couple of weeks writing some test code and trying out Moq for the first time.  Once I started to see what these tools offered, I realized the development friction would actually be lessened by viewing the application's development with a TDD bent.  Then, with enough mind-numbing focus during my time in traffic, all of the puzzle pieces fell into place.

I have to say, this new perspective has added a new level of excitement to my development; it's empowering.

With that, I've settled on a tech stack:

  • MS Windows Server 2008 R2
  • MS SqlServer 2008
  • ASP.NET MVC 2 (beta for now)
  • nHibernate
  • Fluent nHibernate
  • Moq
  • MS Testing Framework (I like the integration with the IDE)
Now, my choice to use nHibernate is the topic of another discussion.  I have always been firmly against OR/Ms, but nHibernate impressed me so much that I decided I couldn't go wrong - as long as I take to the time to understand how nHibernate is expected to be used.  

I will say that I started down the LINQ path with great enthusiasm, but it really had all of the bad elements of an ORM and none of the good.  I can't live in a world with out POCOs, sorry.  I will not "work around" any library - they are supposed to help make things easier, not bleed their abstraction all over your code. *stepping off my soapbox*

Perhaps I'll go into my decision to use nHibernate after I get some hours behind the wheel so I can reflect on my decision.

 

 

Comments

12/10/2009 10:26:30 PM #

I too initially enjoyed the "built in" testing framework Visual Studio 2008 offered, but don't you get tired of having that entire separate project in your solution?  Do you know of a way to mimic nUnit where it's just within your code with a fixture tag?

Bob Manz United States

12/11/2009 1:11:29 AM #

Well, typically you want to keep your tests as separate from your code as possible;  doing this helps to ensure that your logic is sufficiently encapsulated.  Additionally, I personally wouldn't want to publish assemblies that were bloated with tests, sure you could #ifdef regions, but having separate test assemblies just seems cleaner.

I don't know that there's anything technically preventing you from having tests within another project, though I've never tried it.

Ryan United States

Comments are closed

About Me

thumbnail I'm a software developer currently employed by Pearson (PSO/PSON)* where I work with, my passion, .NET.  I have (close to) two decades of programming experience and I'm constantly trying to learn new languages, technologies, practices, etc.

 

Disclaimer

* Emerle.net is owned and operated by Ryan Emerle. The views expressed on this blog are his personal opinion and do not necessarily reflect the views of his employer or clients.

The same holds true for comments posted to Emerle.net; they are the comment posters' personal opinion and do not necessarily reflect Ryan Emerle's views or the views of Ryan's employer or clients.