I Mock You (And I Don’t Even Know It)

Leave a reply

I attended an Agile Iowa meeting for the first time June 15th (when I first started writing up this post…), and walked away with a head full of ideas and aspirations. But I had come with a purpose first and foremost. I was there to get some insight from other professionals on how to improve quality on my current project.

Toward the end, we talked extensively about various uses of TDD, all of which I had heard of, but only some of which I had used in development. But the idea of using mock objects really made an impact on me.

Which brings me to NMock, an interesting tool for incorporating mock objects into your unit and acceptance testing. So far, I’ve only had the chance to test out the introductory tutorial, and my impressions of it are mixed. A google search returns sites with different types of examples, some of which referring to objects I couldn’t find in the assembly for .NET 2.0. But the documentation on the download site looks pretty useful, once I have more time to read through it.

In the coming weeks, I hope to find more time to play around with it, and have more to say on the subject. Stay tuned…

A New Endeavor

Leave a reply

It’s been a few weeks since my last post. I’ve been trying to find time to write more on here – I know I have a few topics I want to cover, but I just haven’t had time to finish any drafts.

In the meantime, I’ve taken over as webmaster of the Des Moines Rowing Club web site. It’s a fairly light-weight job, mostly consisting of updating the meeting minutes and calendar every month, as well as any other changes in content that they request. Previously, the web site was written in SHTML, but over time, I’ll be converting it over to PHP so to make it more robust and maintainable.

Looking through the web site, I’ve considered how I would take an agile approach to converting it over to a more server-side language. Following the UP approach, I would have a type of inception phase where I could identify the stakeholders and define an overall vision of what the end-goal of this project would be.

Then again, with a commitment of a few hours a month, any software methodologic approach may be a bit overkill… = )

Adding Abstraction to Your Designs

Leave a reply

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

1 Reply

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

Leave a reply

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.