Technical Debt

In this post, the venerable Martin Fowler expounds upon his definition of a technical debt in contrast to Uncle Bob’s definition.  Not that they are completely different, but that Uncle Bob views an ignorant mess as not qualifying as a technical debt. Martin considers a mess also a debt, and I agree.

In fact most all development has a certain debt aspect in terms of the metaphor for required maintenance later on. The point of good design and clean code is to empower productivity and easier maintenance. Even a non-decision on design, such a mess, is still a decision. You still have to maintain what was done.

I’m certainly not the sage of good design & patterns like Uncle Bob or Martin Fowler. I do strongly advocate principles for clean code and easier maintenance. That’s why I advocate Test Driven Design and Object Oriented design patterns. It tends to make your code evolve in a direction that is clean and maintainable. It does make you more productive because you are getting feedback on your decisions much quicker than, say, Waterfall style development does.

A lot of what is said in the internets is subjective. What I mean by clean code may be slightly different than what people like Martin or Uncle Bob mean. (although I like to think I write some rather poetically readable, clean code) It’s still subjective. The practices you choose have a lot to do with how clean it will work out, so choosing the right practices – and values for that matter – is highly important. It makes a difference now and an even bigger difference later when you have to maintain your code. ..or that axe murderer psycho programmer who knows where you live has to maintain your code. That’s when you REALLY want to have clean code with low technical debt!

Confession: Never built an NHibernate app

  For all that I do to push for better software design and testing, my job is to build the software my client wants in the environment they choose.  I’m pretty fortunate and have had good clients, but everything isn’t always done according to me. That’s life. So I’ve never built an NHibernate based app. Not truly anyway. I have built stuff on Castle ActiveRecord (built on nhib), which was great! Now I’ve got a project I work at once in a while which I have complete control over. I’ve rewritten it a few times, and this last time chose to use ASP.Net MVC, NHibernate, FluentNhibernate, and FluentMigrator. I’ll be using either nUnit or xUnit for testing, and probably RhinoMocks for mocking.  Oh yeah, any IoC will use Castle Windsor.

  This is a little bit of new ground for me so I’m treading slowly. It’s easy to forget to separate integration tests from unit tests especially since my current client project doesn’t. I find myself struggling to choose how to do certain things like initializing the database schema which is done with FluentMigrator. I want a nice migration experience, but I’m not sure if I want it to automatically update schema without any user action. You can get into trouble with that if there is a problem with the migration; it can cause an infinite loop of attempting to update the schema.

  Also, I nearly fell into the trap of requiring updated schema for the unit test.  Unit tests shouldn’t need schema because they should not be testing database integration. Integration tests will need that, and will test that the data model behave properly when using the database.

  What is great about this is that it forces me to improve, which is a big part of the reason why I’ve rewritten this a few times. This is also my first time working with ASP.Net MVC (have used and love Castle Monorail) but it’s just MVC again with whatever dialect MS put on it. The team behind it are excellent so I’m expecting good stuff. I’m open to input, especially with testing UI. I haven’t done much of that and plan to with this project. Let me know any recommendations.

  I’m not sure what will happen with this little stealth project and don’t want to tip my hand yet. ..but here is a little, carefully redacted teaser:

   1:  Delete.ForeignKey("FK_TimeEntries_UserId");

   2:  Delete.ForeignKey("FK_Companies_UserId");

   3:  Delete.ForeignKey("FK_Approvals_UserId");

   4:   

   5:  Delete.Table("Companies");

   6:  Delete.Table("TimeEntries");

   7:  Delete.Table("Users");

-j

Var – A Warning

I try to learn and reflect on my code style regularly. I occurred to me the other day that my use of the var keyword could be better.  I had started using var for every declaration in my c# code. It looked like this:

   1:  var elementList = new List<FieldElement>();

   2:   

   3:  var resourceKind = (new T()).ResourceKind;

   4:  var schema = GetSchema(connection, resourceKind);

   5:   

   6:  var complexTypeName = GetSingularTypeName(resourceKind);

That’s great and all but it’s not immediately clear what schema and complexTypeName variables are just by reading the code. I suggest using the specific type in declaration of those variables like this:

   1:  var elementList = new List<FieldElement>();

   2:   

   3:  var resourceKind = (new T()).ResourceKind;

   4:  XmlSchema schema = GetSchema(connection, resourceKind);

   5:   

   6:  string complexTypeName = GetSingularTypeName(resourceKind);

That’s better.  As a matter of personal opinion, you might want to change the resourceKind declaration to this:

   1:  string resourceKind = (new T()).ResourceKind;

The T defined in this case so I know what type it is, but it might not be obvious to other people. Clarity is important for maintaining code. Don’t assume that because you know what you were thinking now that you will remember later. One oft repeated rule is to code as if the next guy to work with your code is a homicidal axe murder who knows where you live.

OO For Humans Part 2

Outline:

• Introduction
• Inheritance
• Polymorphism
• Abstraction
• Encapsulation

Introduction

  In the last post in this series, I talked about Object Oriented Programming in less technical terms. We’re going to jump into the deep end here though. You see, I’ve already explained this stuff. Now I’m just telling you the technical terms for it. Hopefully even if you are not already a programmer, you will understand this stuff after.

Inheritance

  Ok, the first one is a curve ball. I haven’t clearly talked about inheritance (technical term, not financial). It’s not hard though. Going back to the Hammer example we’ve been using, let’s say you want to make another hammer that does everything exactly the same but doesn’t smah your fingers if you miss the nail. You can do that, and you don’t have to build a whole new hammer. Just use the same one as before, but add a smarter new case around it. Like this in c#:

   1:   

   2:  public class SmartHammer : Hammer

   3:  {  

   4:    public override void OwwThatReallyHurts()

   5:    {

   6:    }

   7:  }

   8:   

   9:  //from our old hammer...

  10:  public virtual class Hammer : IHammer

  11:  {

  12:    public string Color = "red";

  13:    public virtual void Swing()

  14:    {

  15:    }

  16:    public virtual void Nail()

  17:    {

  18:    }

  19:    public virtual void Break()

  20:    {

  21:    }

  22:    public virtual void OwwThatReallyHurts()

  23:    {

  24:    }

  25:  }

  Some of you may notice the extra word in the old hammer code: virtual. That’s just a C# keyword that tells the computer that the new hammer can do something different.

  So we have our new hammer, and we can make it better by changing OwwThatReallyHurts(). Like this:

   1:  public override void OwwThatReallyHurts()

   2:  {

   3:    DontHitMyFingers();

   4:  }

  That’s hit.. I mean, it. (Yes I really did type “hit” at first, and decided to roll with it.) You made a better hammer with minimal work, and it does all the same things as the old hammer with the exception of that one change.

Polymorphism

  So by some magical coincidence, that altered method, OwwThatReallyHurts, happens to be an example of Polymorphism. Polymorphism is the the ability to override a default and make it do something else. That is exactly what we just did. We took the Hammer class and all it already did, but changed one method by overriding it. This is what “virtual” and “override” are for in the above samples. Virtual tells the code that, yes, you can change me. Override tells the code that, yes, I am going to change this code.

Abstraction

  An abstraction is basically hiding details so you don’t have to think about too many things too deeply all at the same time. The fact that I’m using sample code which doesn’t define every single piece of code is an abstraction. Specifically, DontHitMyFingers() is an abstract placeholder for some undefined code. It doesn’t really matter what it does, as long is it does it correctly. I could have used sample code like this:

   1:  public override void OwwThatReallyHurts()

   2:  {

   3:    if(hammer.location - fingers.location < 100)

   4:      hammer.move(-10, "feet");

   5:  }

  It really just doesn’t matter though, not in order to understand what polymorphism is or the other points made here. For this point it does matter. It is exactly the point, and so is the fact the Hammer has the code for Swing() but SmartHammer doesn’t. SmartHammer doesn’t need or want to have that code, it’s only purpose is to not hit your fingers while doing everything else the same. So the code which performs Swing() is abstracted out of the code for SmartHammer; even though SmartHammer can still perform a Swing() action.

Encapsulation

  Encapsulation (define) means to enclose in a capsule or small container. Honestly, it’s easy to confuse it with abstraction. Abstraction is the representation of features while encapsulation is hiding those things which aren’t essential. When you use a hammer, you don’t need to know the physics of how it works in order to use it. That’s encapsulation. You do need to know how use it to swing it. Knowing about the Swing() action without needing to know how it works is abstraction.

   1:  public interface IHammer

   2:  {

   3:  void Swing();

   4:  void Nail();

   5:  void Break();

   6:  void OwwThatReallyHurts();

   7:  }

   8:   

   9:  public class Hammer : IHammer

  10:  {

  11:    public string Color = "red";

  12:    public void Swing()

  13:    {

  14:    }

  15:    public void Nail()

  16:    {

  17:    }

  18:    public void Break()

  19:    {

  20:    }

  21:    public void OwwThatReallyHurts()

  22:    {

  23:    }

  24:  }

  25:   

  26:  void Main()

  27:  {

  28:    //IHammer is the encapsulation. we can still swing it but not know that the color is Red

  29:    IHammer hammer = new Hammer();

  30:    hammer.Swing();

  31:  }

Look again at our Interface and a sample Hammer class (above). If we look at and instance of the Hammer class, we know its red. However, IHammer hides that detail because you don’t need to know it just to swing it.

Conclusion

  Hopefully you can see this stuff just isn’t hard. I hope my explanation has helped you to understand if you didn’t already. There is so much more depth to this and the other areas I’ve covered, but would be overwhelming to both the reader and myself to try to cover all at once. I hope you’ll continue to read my posts and other blogs. If you have any interested, then I encourage you to read a book or take a class. For those already programming or technical, I will be covering topics directed at you soon.

Links:

• http://en.wikipedia.org/wiki/Object_oriented
• http://en.wikipedia.org/wiki/Inheritance_(computer_science)
• http://www.astahost.com/C-Tutorial-Lesson-5-Encapsulation-and-Abstraction-t15427.html
• http://gpwiki.org/index.php/Object_Oriented_Programming:Abstraction
• http://en.wikipedia.org/wiki/Abstraction_(computer_science)
• http://en.wikipedia.org/wiki/Information_hiding
• http://en.wikipedia.org/wiki/Polymorphism_(computer_science)

-j

Interfaces For Humans

Everyone in the developed world knows what a hammer is and how it looks. We can all operate one to varying degrees regardless of the color, shape variation, or size. You swing it. It pounds nails or breaks drywall/etc. It hurts your finger when you miss and hit your hand by mistake. Pretty standard and easy to understand.

You should try to view your code in the same way. You want it to be easy to use, easy to maintain, and very understandable by the right audience. Using an interface to define what it "looks like" is how to do that. Instead of saying "this is a hammer", you are saying "this is a hammer class." That tells the user that he can swing, nail things, break things, and hurt fingers.

public interface IHammer
{
void Swing();
void Nail();
void Break();
void OwwThatReallyHurts();
}

That is an example of an interface in c# to tell us what a hammer class would look like.  It has methods (aka actions) for swinging, nailing, breaking, and getting your fingers hurt. But I don't recommend the last one. At all. So, OK, great but what good does that do? Well, we now know exactly what something does and how to use it no matter what color/shape/size it is. So let's make a couple hammers. Please notice the use of ": IHammer" in the following code, which is saying this is a hammer.

public class YellowHammer : IHammer
{
   private int swingCount = 0;
 
   public void Swing()
   {
      swingCount++; //just tracking how many times you swing this
   }
 
   public void Nail()
   {
      //thud
   }
 
   public void Break()
   {
      //bam
   }
 
   public void OwwThatReallyHurts()
   {
      throw new HostpitalException("you need reconstructive surgery");
   }
}
 
public class PlasticHammer : IHammer
{
   
private int swingCount = 0;
 
   public void Swing()
   {
      swingCount++; //just tracking how many times you swing this
 
      if(swingCount>10) throw new TopOfHammerFallsOffException("you cant really use plastic hammers, buddy!");
   }
 
   public void Nail()
   {
      //plink
   }
 
   public void Break()
   {
      //tap
   }
 
   public void OwwThatReallyHurts()
   {
      throw new PansyException("it doesnt hurt that much. its just a plastic kids toy.");
   }
 
}

So now you have two hammers, and you know exactly how to user them. BUT. They don't behave exactly the same. One is plastic and one is a nice, solid yellow hammer. The plastic one falls apart if you swing it too many times, and the metal leaves a mark if you hit your fingers. At this point, its all obvious to me that this is good and useful, but I don't know that everyone sees it that way. Since the goal is to explain it simply and clearly, Let's look an example of how to use it.

IHammer hammerInstance = new YellowHammer();

hammerInstance.Swing();
 
IHammer hammerInstance = new PlasticHammer();
hammerInstance.Swing();

You see in the above code you can do the same thing with both hammers. It doesn't matter if one is yellow and one is plastic. Now let's get a hammer without paying attention to what kind, and then use it.

IHammer hammerInstance = MyHammerStore.GetNewHammer();
hammerInstance.Swing();

The magical MyHammerStore gave us a hammer. Since we know how to use a hammer, we just use it. It just works. If all you care about it swinging the hammer, then you don't care what it looks like; just that you can swing it. This is an oversimplified example which hopefully makes the principle easy to understand. How, why, and when to use it would take more time to explain. To give you an idea of a real-world-like scenario, imagine you are writing a school grading application. You will want to save a grade for a student. Your code might look a little like this:

IStudent student = MyClass.GetStudent(studentID);
student.SaveGrade("history class", "A+");

You don't care what the student class looks like, just that you can save the grade on the student record. You don't care where or how its saved; only that it is saved and you can look it up later. Simple. Easy to understand and use. Done.

references

• http://msdn.microsoft.com/en-us/library/87d83y5b(VS.80).aspx 
• http://msdn.microsoft.com/en-us/library/aa260635(VS.60).aspx

TDD And Design Observation

This isn't part of the 'for humans" series; it's just an observation from my current work. I'm in the middle of some brownfield development (enhancing or adding to a program that already exists and is actively developed). So the application I'm working with doesn't really support unit testing. All the pieces are too tightly tied together, but we are working on it as we go. For example, I just added some code that looks a little like this:

[code:c#]

public interface IState
{
  bool IsConfigured {get;}
  void ClearState();
}

[/code]

 Using this interface I can test some of the code that uses it. It's nice because my unit tests tell me if it works and I don't have to run the whole app. Plus I get the benefit of being able to work on whatever part I want to: middle layer, UI, data layer. It's nice to be free.

However, I have to write lots of code that goes right into the rest of the app that I can't test easily. Something like this:

[code:c#]

public class Import
{
  void ImportStuff ()
  {
    IState state = GetTheCurrentState();
    if(state.IsConfigured) RunImport();
  }
}

[/code]

With that I have to start the whole app and test it manually, which also means I have to build some rudimentary UI to execute that code. This is called top-down design when you are basically writing UI and top level features before writing middle layer, business rules, and data layer code. It doesn't lend itself to a good design and maintainability. For whatever reason, it just occured to me that developing that way tends to force you into it, which also leads to more pain points in the application.

Test Driven Design definitely has the advantage here. More Freedom, more fun, better code. Trust me.

-j

Agile For Humans

"Be Water my friend" - Bruce Lee 

Wow! Go ahead and watch that again; I'll wait right here.
 
So you might be asking "Why Bruce Lee", and I would answer "because he's accessible/understandable." Also, the quote is somewhat relevant to the topic, which is how to develop software. By that I mean what process you can use to guide a project to completion. Sure you could go all cowboy and make things up as you go, but that doesn't generally work well. I know; I've done it. It is important to have some sort of process to drive things along and check your progress. That's really important if you are working on a schedule.
 
In this "For Humans" series, I'm trying to gently introduce software development in non or less technical terms. This is a bit tougher topic, but I will do my best.
 
There are lots of ways to do lots of things, or as they say where I grew up "there's more than one way to skin a cat." Never did understand why you'd want to skin a cat. You can't sell the pelt, and it might be illegal. Thankfully software development is definitely not illegal. Though some people say managing developers is like herding cats, skinning developers is DEFINITELY illegal. And really creepy. One traditional approach to managing software development is called Waterfall. It is strict although you can implement it in lots of variations; and the basic idea is do all the design up front and then don't veer off course.
 
Waterfall takes a lot of ideas from engineering disciplines, but software development really doesn't fit well into that model. Things change, flaws are discovered, and assumptions turn out to be wrong. To address this, a set of principles has been identified and named "Agile." No process is perfect, but Agile is rather good at adaptation, and can also be implemented however makes sense for your business or project. This is the "be like water" moment.. please pause and let the enlightenment flow from my text to your brain. Software development requires adaptation, and Agile (or XP or Scrum) is a process for managing changes in development.
 
It's a little like learning English. There are rules, but there are also exceptions. "'I' before 'E' except after 'C' and when sound like 'A' as in neighbor and weigh ..or in seize, or weird, or.." It comes down to knowing the principles and practising. In truth, I don't practise all the rules all the time. I'm not an elitist, but a pragmatist. What happens in practising is you naturally get better (obviously) and you develop better intuition about how to apply your practices.
 
Agile core principles can be found here, and core values/manifesto found here. I'll leave it to you to read those, because what's more interesting are the practices.
 
Test Driven Development (link)
This is where I do get more serious, and have already blogged on it some here(http://computeristsolutions.com/blog/post/Unit-Testing-is-for-humans.aspx). There are reasons why I'm passionate about this. For one, it really works. By writing tests first, you are really setting expectations of how your code should behave. After that, there's a natural evolution of your code into something that works, has fewer bugs, and becomes a good design. Please go back and read my earlier article for more info.
 
Behavior Driven Development (link)
From test driven development, this was a natural evolution. It's focusing on the expectation part of writing tests first; only it strives to express the intent more clearly using conventions. I'm not really sharp on the distinctions, so I recommend you read more on it yourself. Jean-Paul Boodhoo blogs often about it, and is a good resource.
 
Continuous Integration (link)
Here's another activity that will really help move your development along. Even if you are the only developer, setting up an automated build of your code will help you catch problems sooner. Think of it like driving. You wouldn't want to drive down the road with your eyes closed and only open your eyes every so often to get a peek of what is going. You want your eyes open all the time so you know what's going on around you, which is what continuous integration does for you. Kent Beck's XP books talk about getting early feedback and this is part of how you achieve that.
 
Pair Programming (link)
OK, so here is where I can't pretend to be an expert or anything like it. I don't do pair programming. I'm not saying I wouldn't or you shouldn't; just that I am not in the situation of being able to. Many of those that have swear by it. Even Ayende (everyone should read his blog) pairs up. I've certainly seen the benefit of code review. So I guess I see how this would basically be continuous code review. I do recommend considering it, especially if you are just getting into coding and can pair with someone you can learn from.
 
Agile Planning (link)
This can actually be fun. You divide up your project into small, reasonable tasks. You can use these tasks for estimates. Pick some to get done each week. Let the devs pick which tasks to do. Many agile articles suggest actually have real memo cards with each task on a board or basket to choose from. It certainly helps avoid overlap between developers. You can use the task card to plan and estimate the project to. Just estimate each task, and get help to arrange them in order of which must be done first with the remaining filled in. Simply put, breaking things down to their smallest logical part makes planning, estimating, assigning, and adjusting all easier. It's almost zen-like how it will fall together.
 
Short Meetings
This is more of a Scrum attribute than specifically an Agile attribute, but it's one I find highly useful. Keep the meetings short. Try meeting everyday for 10-15 minutes just to share status. Stand up the whole time to discourage long conversation. If something needs discussed longer, schedule a meeting or casually meet outside of the short meeting; and include the least number of people needed. Less time meeting is more time producing.
 
Conclusion
Hopefully this introduction to Agile wasn't too boring. It's tough to cover this in short and simple terms. My usual stories would take up too much extra space, and I couldn't write an in-depth article on Agile in my few spare minutes over a few nights. To learn more, read online articles and pick up Ken Beck's XP book. I recommend learning Agile if you are just starting in development, or already have but don't yet know it. You should also learn about Waterfall so you understand traditional software life cycles.
 
Those in the know, will probably notice that I mixed information about Agile, Extreme Programming, and Scrum. It's all related, and I don't have the time or space to cover it all in detail. I hope this suffices as a reasonable introduction. If I could beat one thing into your head with a really big, shiny hammer which has a red, non-slip handle, it would be that you should follow some process. I've been down the cowboy coder path, and the waterfall path. I recommend using Agile/XP/Scrum practises in most cases.
 
Additional resources:
A good read in this area is Kent Beck's Extreme Programming Explained 2. Yes it's geared to a technical audience, but I think its readable for everyone.
A little Scrum intro video: http://www.youtube.com/watch?v=Q5k7a9YEoUI&feature=related
Extreme Programming: http://en.wikipedia.org/wiki/Extreme_Programming
XP Practises http://ootips.org/xp.html
Kent Beck on XP http://www.extremeprogramming.org/
Ron Jeffries on XP http://www.xprogramming.com/xpmag/whatisxp.htm

-j

Unit Testing is for humans

Audience note: this is written for non-programmers or beginning programmers. Don't skip it though, it lays out reasons why unit testing is good. Should also be witty and entertaining. I've been practicing this at the Improv. ;)

When I was a kid, I had one of those AM radio kits that you build yourself. My dad told me a little about electronics, and with the instructions I tried to build it. Several times. I would get to a point where I thought it was done, and put it all together. Then I'd find something didn't work or wasn't right. So I would have to take it apart again and try to figure it out. After doing this a few times, I realized it was easier to check the soldering, wires, and knobs as I went along before putting it all together in the cheap case. I got it partly working with a nice, clear static sound before I lost interest and used the parts for something else. It was a good lesson though.

It's a bigger pain to find out later something wasn't working than to take the time right away to check it. In software development, we call this Unit Testing. 

What is this Unit Testing you speak of?

Unit Testing is the practice of breaking software into the smallest logical parts and testing that each small part does what it is supposed to do. This also has the effect of driving you to build pieces that you can test and maintain more easily. Testing your code has some very specific benefits: you know it works. The process of doing this also benefits you by creating a path toward a good application where all those small parts work together well.

Why would I want to do that?

helps with design The resulting design (how things fit together) is naturally easier to maintain and fix. Like water flowing down hill, you can more easily tell where its going and where it came from. This makes following it a lot easier. It also makes changing it a lot easier.

helps solve problems  Sometimes you get stuck on how to build a certain piece. You can write the unit test first, which I recommend anyway, and then start writing code until the test passes. In effect, you are first defining what you want to happen. Then trying to make that happen, and you are done when the test passes.

makes maintenance easier If you have a bunch of tests and discover a bug then you can more easily find and fix the bug. If there is a failing test where the bug should be, then start by fixing the test. If the bug is still there, you write a test that will pass when the bug no longer happens. Now make the test pass. In doing this, you are isolating the part(s) where the bug happens which makes it easier to find. When its easy to find, its much easier to fix.

easier for other dev's to figure out Imagine you just started trying to use that radio I kinda built when I was a kid. You have the manual and a not really working radio. If I had tests to go along with each part, you could check each test to see what it does and make sure its right. Then fix the one (I'm sure it was only one) that wasn't working. Smaller pieces are easier to understand, which is important even if you are an expert with the language its built with. Maybe unsurprising is that it's often your own code. It's easy to forget what you did a few weeks, months, or years ago. Having those tests help.

Why doesn't everyone do that?

never heard of it/don't know about it  This is pretty obvious. You're a new developer who is either self-taught or wasn't taught unit testing in school. You learn, you believe, you test the daylights out of everything forevermore.

takes too much time It's true, sorta. It takes time to add unit tests and it can sometimes feel like its too much time. It will save you time when it comes to fixing bugs or adding features. You will have less bugs, and changing things takes less time because you know immediately if you broke anything.

don't see the point Hopefully you do after reading this far. But just in case, remember the AM radio.

my code is good enough without it It's true some of you and myself have coded without unit testing, and did just fine thank you very much. I remember those days: 80 hour weeks to fix the last bugs before releasing a product. Sleepless nights fixing a broken deployment. Yeah, it was great. But I don't much have to do that anymore. That's partly because of experience, and partly because testing my code as I go helps me find problems sooner.

other people keep deleting my tests anyway OK, I hadn't really heard this one before today. I have some guesses as to what may have happened, but it doesn't really matter. The problem is the team wasn't supporting the unit testing practice. It's hard or impossible to move forward with unit testing in a situation like that. The fix is to have them all read this article so I can tell them how right you are. hehe. Really, discuss why it helps. If this article helps explain that then great because that's my point. 

my app is too hard to test I have a lot of sympathy for this; a big part of my day job is in this situation. The closest we could come is called "integration testing" which is basically like unit testing except we aren't breaking it down into smaller parts to test. You don't get the benefits of real unit tests, but it's better than nothing. Work unit testing in as much as you can and build team support. After that, you have to figure out what's next. Sometimes, it's not even up to you.

MbUnit, nUnit, xUnit are all .Net testing frameworks. They include pretty application to run your tests and show you the results; typically green for pass and red for fail. Everything you'd expect after taking Driver's Ed. class. testdriven.net is a utility which helps make running your test easier. These two powers combine to give you nearly unlimited power less work in building and checking your tests. 

These are a few unit testing tools for the .Net developer. There are so many tools to help make it easier to test your code. It's really a life lesson; check your results instead of assuming the outcome is what you expected. It avoids a lot of problems later on even if its a little trouble right now.

Blah blah blah..

To be clear, I am not a zealot (read with Richard Nixon voice). In fact, I didn't code with unit tests when I decided to learn Ruby on Rails about 2 years ago. I would make a rails app and play around then start over. It didn't really matter because it was just throw away code and I only wanted to see how it worked. Until I stumbled on an idea that was actually useful to me. I've slowly worked on it for the last year since I don't have a lot of time for it; and now its about 90% functional. But no unit tests, which is horrible because rails is big on testing. I may have actually been able to complete it by now if I had unit tests, even if I didn't put any more time into it. Now I have to go back and add them because I know it makes a difference.

Time to get back to work. I'm at a point where I need to write some unit test, and I'm excited.

-j

Mocking Justin Etheredge

Justin Etheredge has started a series on mocking using Moq, which is a mocking library that I've been meaning to learn more about anyway. Here are links for the first two posts. 

• part 1
  
• part 2
  

 -j

An MVC Argument for Humans

MVC is all the rage it seems. I really didn't get it at first; that is until I started using it. That was a few years ago. Now it's my prefered pattern for web development. It wasn't originally a web pattern, but it turns out to be a great way to keep things clean in a web application. It's a good convention, in my opinion.

Now it's not always the best choice. It depends on your needs. It certainly takes extra work if you're going to build it yourself, but chances are you don't have to. Several frameworks have sprung up to fill that void. Probably the most famous is Ruby on Rails. It's obviously for the Ruby language, and there are others out there for Ruby. There are frameworks for PHP, Java and .Net as well.

We mostly work with .Net (with a dash of Ruby) so let's talk about that for a minute. In my opinion, there are 3 major MVC frameworks for .Net.

• ASP.Net MVC
• Castle Monorail
• Promesh.net

ASP.Net MVC is Microsoft's mvc framework. Castle Monorail is part of the excellent Castle Project, an open source project. Promesh is another open source project, which came from a developer's personal toolbox out or real world use. I'm more familiar with the first two. We use Monorail in our project, so have a little bias. (computeristsolutions.com is built with monorail for example)

Convention

So how often do you look at an old project or old code and think "What was I doing here?" or "What the **** was the other guy thinking? What a moron!" It happens. Sometimes I'm the other moron. It's easy to forget what was going on as time passes. Sticking to a convention helps avoid that. You know the convention, you can follow the code a lot easier. You can find where things are at. Easier maintenance is a big deal, and MVC helps with that. A lot.

Testing

Do you test your code, unit test perhaps? You should. Go. Do it. Now! There are lots of reasons to use unit testing, and its not really my point in this post.. but let's leave it at you KNOW your code works when you commit it to source control. MVC helps and encourages seperation of code so that testing is easier. By doing so you will be able to more properly, fully, and completely test your code. (Also look at Inversion of Conntrol; look at Castle Windsor) The function of a unit test is to test a small unit of code. If everything is lumped together then testing small units gets hard or impossible. It just so happens it makes maintenance hard too.

Design

This isn't really talked about in most MVC articles I've read, but it really is a big time savings in our experience. When you build and maintain a website, you will have to alter or completely change the design and layout. If you're using a MVC framework, it's a lot easier. You typically have a central layout which is used for all or most of your pages. You only have to edit that one layout to change most of the site. If you were careful to make everything CSS friendly, then you have even more power over your site by changing the layout and/or the CSS. Even when a plain HTML site would be fine, I lean towards using an MVC framework for this reason. Site-wide layout and design changes take minutes instead of days or hours.

Conclusion

Hope this brief, humanized argument for MVC on the web makes sense. There are many good choices for frameworks. We recommend Castle, and the upcoming ASP.Net MVC framework looks pretty good. There is a small learning curve in adopting it, but it will payoff big in time and headaches saved. If you need to adapt your current ASP.Net site instead of writing a new one, I'd suggest looking into the MVP pattern. See MVP here, here, and here. Good luck and have fun, which I'm sure you will.

-j