Microsoft put out a nice, introductory article on using TDD in the VSTS environment. Definitely worth checking out if you’re new to the concept.
MSDN Article on Test-Driven Development
Leave a reply
Monthly Archives: May 2006
Adding Abstraction to Your Designs
One principle I have seen when it comes to Agile Development practices is to design the simplest thing necessary to completing the objective. Now, I take this with a grain of salt because I could easily create a straightforward application that is highly coupled, non-cohesive and overall difficult to maintain in a real-world environment of ever-changing requirements.
So, given that I will at least put in the effort to use good OO design while still doing the simplest thing to reach my objective, I feel that there are times when adding a little abstraction to your designs is a simple task that can benefit you greatly down the road.
As a rule of thumb, I almost always stick at least one controller class in my business tier to mediate between my business objects and my user interface layer (or persistence layer, for that matter), regardless of the size of the application. There are several benefits to doing this:
- It is a better place to keep business rules than in your UI, especially if the business rule applies to several screens. This helps in lowering coupling between objects.
- It lowers the overall responsibility of your business classes, keeping them highly-cohesive.
- If When your business rules change, there will be fewer places that you’ll need to make your changes (ideally, only one spot: a method in your controller class).
To paraphrase one of my old college professors: It is better to have too many (software) classes than too few.
Lunch Meeting
I met with Tim Gifford today for lunch, and had a really good discussion on using agility in the workplace. It was nice to talk to somebody else who has had some experience with TDD and paired-programming and it was reassuring to know that people are benefiting from these techniques.
I guess, in my case, my failure using agile techniques was a matter of inexperience. That, and the fact that I was working by myself on a project, which is difficult in an agile environment, since a big focus is on collaboration — with stakeholders and developers alike.
Tim made a good point about the importance of multi-developer project teams: Part of the responsibility of a developer in a team is to make sure other developers are not “rushing to the finish line” of development. That is, making sure that others properly test their changes or new code before sending it off.
He also gave me some good tips on how to start changing my work environment in small, progressive steps. For example, start with unit testing. By building automated tests throughout development, it is easier to prove that your application is handling the business rules correctly. In addition, you can work with the client to develop these tests for real-work cases and use this as part of testing toward the end of the project, allowing the test users to focus on other aspects of testing.
A Different Way to do Version Control
One of the best features I like about version control systems is the ability to do a line-by-line comparison between a local and checked-in file. Of course, there are times when I want to do that with other text files that I would otherwise not keep under source control.
Now it is possible, with a cool little utility application called WinMerge. In the absence of true Source Control, this free app can be a time-saver when moving source files between environments. For those of us who do personal web development, but aren’t hardcore enough to have a separate server with version control functionality, this is a great little tool.
Of course, I would never recommend this tool over an actual version control system.
Refactoring Idea
As I was refactoring some of my code at work today, I found another example of refactoring that would come in handy: De-sugaring code segments that are syntactically sugared.
In my case, I had to support a changed business rule that required nullable DateTime objects instead of ValueType DateTime objects. So I tried to change
DateTime dtNull = ( /* my condition */ ) ? new DateTime() : DateTime.Today;
to
DateTime? dtNull = ( /* my condition */ ) ? null : DateTime.Today;
Of course, Visual Studio gives me a compiler error if I make this change because “there is no implicit converstion between <null> and ‘System.DateTime'”. However, the following does work:
DateTime? dtNull;
if ( /* my condition */ ) {
dtNull = null; }
else {
dtNull = DateTime.Today; }
It seems that refactoring something like this should be very easy to automate. Unfortunately, to my knowledge, Visual Studio 2005 is not as extensible in the area of refactoring as it is in the area of Code Snippets.