Running through a recent code review on an outsourced internal project I came across a new issue. The developers have built a few SharePoint Web Parts in using ASP.NET. I gently asked where the unit tests where since I’d dug around in source code and not seen any.

The developers looked a little surprised and sort of thought I was talking about manual unit testing, but I reiterated that I meant NUnit or MSTest unit tests. There was a short discussion. What followed was they couldn’t see how they could unit test the Page Behind code. This is an unfortunate old story.

Testing controllers in most web frameworks is painful. The classic example is Struts Action classes where you can use StrutsTestCase, but the solution isn’t elegant. JSF was an even worse experience, especially the 1.0 spec. Lately messing around with Grails has made it a bit easier, but I still find it to test the controllers through a front end functional test like Selenium. Of course in Rails it’s fairly trivial.

I’ve followed some agile bloggers in the MS world for some time and I knew this problem existed in the ASP.NET world. I knew a lot of them advocated a model-view-presenter (MVP) design to allow for easy unit testing. I assumed with Microsoft MVC out now that this problem is solved. It appears to be a much better story, but currently Microsoft MVC doesn’t integrate directly with Sharepoint.

The next step was to find a specific library. It turns out there is one much like StrutsTestCase or other libraries that make it easier to test web controllers. NUnitAsp to the rescue, coded by no less than James Shore. Then I read the note on the front page from about a year ago:

NUnitAsp still has some dramatic flaws: no support for Javascript, tests running in a different process than ASP.NET, difficulty setting up sessions. Most people ended up using it for acceptance testing, rather than unit testing, and Selenium, Watir, and the like are better for that. Most folks “in the know” are using presentation layers to make ASP.NET so thin that a tool like NUnitAsp isn’t helpful.

— James Shore’s note on NUnitASP Development

So much for a silver bullet. Ever the optimist I had hoped for something like this:

• Quickly find a nice explanatory tutorial and send the developers the link.
• Answer a few questions as they experimented with their first tests.
• Hook up the project to a continuous integration server and start running the tests.
• Next code review we talk about the adoption of an MVP approach.

Looks like this is going to require some more work.

As a developer you get the occasional fire drill where some application is crashing at 3 am and you walk into a mess at 7 in the morning. You had expected to spend the day adding that cool new feature, but now you’re digging through reams of log files and looking at environmental issues.

Imagine that amplified about 10 times. Managers plan for coming in doing some strategic items like outlining an Agile rollout strategy or writing justifications to upgrade development hardware. Instead you’re pulled aside by the CIO who’s asking about some serious security breach. In the midst of digging into that a PM stops by to inform you that the project just lost its tester and you need to help them scramble to cover the role. By lunch you’re hunched over your computer catching up on the 100 emails you were ignoring when you find an outside customer asking how to connect to your external API forwarded from the head of customer relations.

They can be really frustrating days and throw off your progress on the bigger goals. The key is to try to recover and come in fresh the next day. Fire drills don’t last that long generally. If it goes long we’re probably talking about a Death March project and those are something to avoid where possible.

So if your boss is running around a bit frenzied asking for quick updates, and looks like she skipped lunch they’re probably stuck focusing on tactics over strategy.

Saturday

1:15 Build Broken

1:22 Build Broken

1:46 Build Fixed

Sunday

9:18 Build Broken

9:26 Build Fixed

Active healthy projects have a rhythm. The scenarios look like:

• The project rarely has any active development. Broken builds are a complete surprise. If you know someone is coding on it, you need to quickly provide some feedback on regular check ins.
• Active projects with teams new to CI have a lot of broken builds which are generally quickly resolved.
• Active projects who’ve worked with CI servers for a while tend to have long periods of calm with the unusual broken build. Often the broken build is due to some minor config item sometimes with the CI server itself.

As a manager in a shop with dozens of independent projects running the CI server is your best friend. The example email pattern was from a typical scenario over the weekend. Without doing more than scanning email subjects on my phone I could tell that a contractor was working over the weekend and adjusting to having automated builds. Gives you a extra bit of confidence.

Automated testing is one of the most important parts of software development, and yet until now, we haven’t mentioned it. Testing a piece of software relies on a thorough understanding of the tools you are using, and designing tests can be far more difficult (and enjoyable) than writing the code itself.

— Head First Rails pg 407

Despite Rails effort in making testing easy the Head First Rails book ignores testing altogether until a slight mention on one of the very last pages of the book. I perused the index hoping I was wrong, but the author spells out that it was a deliberate decision.

I have a lot of respect for the Head First books as a great way to jump in and learn something new. I’ve posted before about how impressed I was when Head First Software Development went into depth on Agile and testing. Here I’m just saddened by the decision. Even a short appendix with a few examples might have sufficed if not examples throughout or a dedicated chapter. All the other Rails books I’ve come across at least devote some time to the testing conversation.

Say No. This is your second most powerful tool. Whether you’re a manager, considering management, or just here for the Rands, I want you to pick the hardest problem on your plate. The one that is waking you up at 4am. I want you to decide and to say out loud:

“No.”

You’re not going to do that thing. QA can’t test it. Engineering won’t finish it. If we attempt to do it, we will fail and we don’t fail, so the answer is “No”.

— Rands

Rands spells out the importance of saying no. A critical point in plotting your strategy is saying no. After a good round of brainstorming you’re itching to start 5 different major initiatives. Maybe customers want to get started on new features as you’re still trying to launch weeks away from launching the baseline app.

The tough answer as a manager is often no. Agreeing to a impossible deadline and attempting to toss quality aside is bad for your team and bad for the organization. Saying no is the right thing here.