Designing for Testability

Posted by indomitablehef | Filed under TDD

I was doing a bit of refactoring today, in an effort to make my application more testable. I was getting rid of a singleton, which reminded me of this presentation, which I attended at the QCon 2007 conference in San Francisco. I did a search for it, and it turns out it’s recently become available online at InfoQ. The first 22 minutes is about an open-source  Java testing framework called TestNG, but then they switch gears (and presenters) to talk more about “designing for testability”. It’s a good, honest, and realistic discussion about the tradeoffs we make in order to make our code more testable.  Check it out…

AgileOfficeEssentials.com

Posted by indomitablehef | Filed under Agile

Monday marks the official launch of my new blog/business idea, “AgileOfficeEssentials.com“:

AgileOfficeEssentials.com is about the work environment, equipment, and supplies that enable Agile software development teams to work more effectively. It’s about working arrangements that enable both collaboration and concentration. It’s about creating an environment that encourages innovation and creativity. It’s about breaking free from cubicle-farm despair and “open office” frustration. It’s about being Happy where you work.

In its current incarnation AgileOfficeEssentials.com is a blog devoted to the physical trappings that make an Agile Office: Office layout, agile teamrooms, pair programming setups, Caves and Commons, whiteboards, Information Radiators, continuous integration build indicators, sit/stand desks, etc. Check it out, tell your friends/boss/space planner, and please feel free to comment/discuss.

ViEmu

Posted by indomitablehef | Filed under Visual Studio, Tools, Productivity

Back when I was in college, my first computer science professor insisted that everyone learn to use the Unix text editor Vi. After my initial few weeks of frustration, I was hooked. I could really fly on the keyboard, without ever using the mouse or the arrow keys to move around. I got my degree, got a job, and I haven’t seen Vi since.

Until now. This nifty little Vi emulator (ViEmu) can emulate Vi in Visual Studio, SQL Server Management Studio, Outlook, and Word. I found it after reading about it from jpboodhoo, and these screencasts from Aaron Jensen at Eleutian (part1, part2, part3) helped me get started. I must say, it’s still painful…relearning all this stuff. I’m currently slower using ViEmu than I was a few days ago without it. But I’m beginning to see the productivity at the end of the tunnel. (I found myself hitting “hhhhhh” several times while writing this blog post.)

more ViEmu goodies:

• Graphical Cheat Sheet and Tutorial
• Tips on Effective Editing with Vim
• Why, oh WHY, do those #?@! nutheads use vi?

NAnt, Copy, and Embedded resources

Posted by indomitablehef | Filed under NAnt

Can you tell the difference between these two NAnt copy tasks?

<copy file="src/app/MyProject/Data/Mapping.config" todir="build" overwrite="true"></copy>

<copy file="src/app/MyProject/Data/Mapping.config" tofile="build/Mapping.config" overwrite="true"></copy>

The first one will copy Mapping.config to /build/Mapping.config. The second one will copy Mapping.config to /build/mapping.config

That’s right, it “lower-cases” the filename!

Figuring that out was incredibly frustrating, because when you are embedding the Mapping.config file into your .net assembly like so…

<csc target="library" output="build/${project::get-name()}.dll" debug="${debug}">
	<sources>
		<include name="src/app/**/*.cs"/>
		<exclude name="src/app/MyProject/*.*"/>
		<exclude name="src/app/**/AssemblyInfo.cs"/>
	</sources>
	<resources basedir="build" dynamicprefix="true"/>
					prefix="${project::get-name()}.Data">
		<include name="Mapping.config"/>
	</resources>
</csc>

…it matters a whole lot whether your embedded resource is named mapping.config or Mapping.config. Your assembly won’t find the lower-case-named embedded resource. Easy solution? Just give your resource files lowercase names, I guess. Otherwise, use “todir” in your <copy> task instead of “tofile”.

Getting Real

Posted by indomitablehef | Filed under Agile

I just finished reading Getting Real, a book by 37 Signals. I can’t recommend it highly enough. Their own promo review quote says it best:

“Every once in a while, a book comes out of left field that changes just about everything. This is one of those books. Ignore it at your peril.”

-Seth Godin

You can read it for free online, or buy a PDF or paperback.

Here’s a quote:

A happy programmer is a productive programmer. That’s why we optimize for happiness and you should too. Don’t just pick tools and practices based on industry standards or performance metrics. Look at the intangibles: Is there passion, pride, and craftmanship here? Would you truly be happy working in this environment eight hours a day?

and another:

Functional specs only lead to an illusion of agreement
A bunch of people agreeing on paragraphs of text isn’t a true agreement. Everyone may be reading the same thing but they’re thinking something different. This inevitably comes out later on: “Wait, that’s not what I had in mind.” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.

and one more:

Our favorite answer to the “why didn’t you do this or why didn’t you do that?” question is always: “Because it just doesn’t matter.” That statement embodies what makes a product great. Figuring out what matters and leaving out the rest.

TeamCity is da bomb

Posted by indomitablehef | Filed under Continuous Integration, Tools

I’ve been working with TeamCity, JetBrains new Continuous Integration product, for a couple of weeks. I’m completely infatuated with it right now. It has a quirk or two to deal with when getting it set up, but configuring builds is much easier than with CruiseControl, and the amount of information it gives you back is fantastic. Logs of your changes, trends on how long your unit tests are running, statistics, it’s nearly overwhelming. The Professional Edition (up to 20 users, 3 agents, 20 build configurations) is just as free as Cruise Control, too.

I did have to make some changes to how I ran my NUnit tests, in order for TeamCity to pick up on them. I had been calling nunit-console.exe from within my NAnt build file, like so:

<exec basedir="toolsnunitbin">
		useruntimeengine="true"
		workingdir="build"
		program="nunit-console.exe"
		commandline="${project::get-name()}.Test.Unit.dll
			/xml=${project::get-name()}.Unit.Test-Result.xml" />
</exec>

While that ran my tests just fine, and output the results to the xml file, TeamCity didn’t pick up on that. CruiseControl.Net picks it up when you add this to the <project> node in your ccnet.config file:

 <publishers>
	<merge>
		<files>
			<file>C:checkoutsMyProjectbuild*test-result.xml</file>
		</files>
	</merge>
	<xmllogger>
</xmllogger>
</publishers>

But that’s beside the point…we’re talking about TeamCity here. For TeamCity to recognize my tests, I had to use the <nunit2> NAnt task, like so:

<target name="unit.test.nunit2" depends="unit.test.compile">
	<copy file="config\Web.Config"
		tofile="build\${project::get-name()}.Test.dll.config" />
	<nunit2 verbose="true" haltonfailure="false" failonerror="true">
		<formatter type="Plain" extension=".txt" usefile="true"
							outputdir="${project.root}\build"/>
		<test assemblyname="build\${project::get-name()}.Test.dll"
			appconfig="build\${project::get-name()}.Test.dll.config"
				haltonfailure="false" />
	</nunit2>
</target>