Month: August 2007

I’m not the only one!

http://feeds.feedburner.com/~r/flux88/~3/141244484/DearVSTSTestIHateYou.aspx

Ben, since MSTest‘s functionality dwarfs that of NUnit’s I’ve found it relatively easy to have most of my tests run in both MSTest and NUnit. Of course, where I used NUnit’s more advanced functionality, I just disable the test in MSTest. Yes, its kind of a hack, but it works.

Each of my test files have using statement sections like this:

#if NUNIT
using TestClassAttribute = NUnit.Framework.TestFixtureAttribute;
using TestMethodAttribute = NUnit.Framework.TestAttribute;
using TestInitialize = NUnit.Framework.SetUpAttribute;
using NUnit.Framework;
#else
using TestFixtureAttribute = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
using TestAttribute = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
using Microsoft.VisualStudio.TestTools.UnitTesting;
#endif

 

Then I maintain two project files. One is a MSTest project, and only opens in Team System edition. The other is a standard Class Library project – the typical NUnit test project. The later defines NUNIT in its project settings. By using type aliases like this, I can use either NUnit or MSTest attributes in my test fixtures. Of course any tests using NUnits Constraint Model Assertions won’t work in MSTest so I’ll either #if def out those tests, or I won’t include the entire fixture in the MSTest project.

Wendy Friedlander, aka “wunda” has an awesome post over at her site. She says:

…

The development environment of many institutions is molded to the vision of software provided by people with no insight.

Pushing irrelevant solutions and deadlines.

Traveling a rote technology line.

Where does that leave the rest of us?

We go with the flow.

We find a place that embraces agile.

We work to change our environment.

It takes a great deal of energy to foster change in your environment.

It takes time, effort, trust and many other qualities that make going with the flow look better and better as time goes by.

You are not alone.

Your company software policies were not created by your company.

They are the practices of the community.

A community that conforms to business and technology providers’ desires and not the interest of creating the best solutions.

…

I love the sentiment, and I love that she is talking about ALT.NET.

“It’s not the tools, it’s the solution.”

This is the phrase that David Laribee used in his ALT.NET post back on April 10th.

I agree, it isn’t the tools. I agree, it is the maintainability of the solution. After “does it work?” Maintainability is the number one concern when I write software.

That said, sometimes “the better way” IS about the tools. I won’t go so far as some others, or as I did previously, BUT (see it is upper case, that means it is a BIG BUT) there are a couple items on the list that deserve to be upper case, or bold, or H1 or Heading 1 or screamed at the top of your lungs while standing on the highest table in the auditorium.

I won’t call it HOT or NOT, I’ll call it Acceptable and Inexcusable.

There are two often used tools which in my opinion have absolutely no place on a well meaning developers project. I’ve given it a bit of thought and I cannot come up with any use case where these tools are the right solution. The answer “they are good enough for our team” is heard by my ears as “we aren’t interested in doing a better job.”

VSS. Yes Visual Source Safe. Lock-Modify-Unlock? What??? At the Visual Studio 2005 launch event I nearly fell out of my chair when the Team System demo showed its Copy-Modify-Merge system. Not because I was impressed. No, I was dumbfounded that the CVS I had been using for 10 years and the SVN I’d been using for a few were so far ahead of what many development groups were using. What wasn’t clear was that VSS2005, while it had a new version, it did NOT change the versioning model.

VSS is inexcusable. If your development organization is using VSS don’t just consider switching. Considering alone would not be enough. DO IT. Switch to ANYTHING! The popular move seems to be subversion, and don’t let the open source fool you. You CAN buy the product and support from Collabnet. It isn’t JUST open source. You get MORE from Collabnet than you do from MS with VSS because if your SVN crashes, they will help you recover and help to find the bug for why it crashed. VSS crashes and is full of known bugs and the answer is to backup your repositories regularly. I’d go on here, but a quick google looking for others citing these VSS flaws shows that Jeff Atwood has already covered this ground. It has been a year so I guess it is time someone else mention it.

I will mention that you might consider changing your SCM paradigm and looking at one of the Distributed tools now available. Bazaar runs great on Windows. Git runs in Cygwin. Mercurial has a windows installer.

MSTest is inexcusable. Yes, the Visual Studio integration is very pretty, but after using NUnit, trying to move to MSTest is painful! It hurts. It hurts bad. When you pile on NUnit’s latest Constraint based testing model, there are MANY things that NUnit can test in only one line of code, that MSTest would leave your writing many many lines of code.

I won’t rant on MSTest nearly as long as I did VSS because I haven’t suffered under its tyranny for nearly as long. Maybe (although I doubt it), with a little more time under MSTest and I’ll be able to bear it, but I stand by my original assertion, it is the wrong choice.

David Hayden over at CodeBetter has a post on performance and LinqDataSource.

The problem that David Hayden describes so well is known as Select N+1. Those of us using NHibernate have been dealing with this since we started using our favorite ORM. There has been much written on this problem.

It is my belief that this is going to be the biggest problem developers are faced with when using any of the LINQ to database technologies. Entities, DataSets, or SQL, it doesn’t matter which LINQ to database you choose. You will have to understand what is going on under the hood a little. David is using the design time features of the LinqDataSource control and he solves the N+1 problem by limiting his functionality.

Not that it solves any of these problems, but MonoRail just keeps looking better. MR doesn’t have a LinqDataSource, but enabling edits and deletes is no different and treated at a different layer in your typical MonoRail w/ ActiveRecord application. These are different concerns. MonoRail w/ ActiveRecord does the right thing and treats them as separate.

Thank you Castle Project!