Windows Azure SDK Unit Testing Dilemma — F5DD Plz K Thx Bye

I’m a huge advocate for high quality code. I will admit I don’t always get to write, or am always able to write high quality code. But day in and out I make my best effort at figuring out the best way to write solid, high quality, easy to maintain, easy to read code.

Over the last year or so I’ve been working with Windows Azure (Amazon Web Services and other Cloud/Utility Platforms & Infrastructure also). One of the largest gaps that I’ve experienced when working with Windows Azure is the gross disregard for unit testing and especially unit testing in a Test Driven Development style way. The design of the SDK doesn’t make unit testing a high priority, and instead focuses mostly on what one might call F5 & Run Development.

I’ll be the first to stand up and point out why F5 Driven Development (for more on this, check out Jeff Schumacher‘s Blog Entry) is the slowest & distracting ways to build high quality code. I’d also be one to admit that F5 Development encourages poor design and development. A developer has to juggle far too many things to waste time hitting F5 every few seconds to assure that the build is running and code changes, additions, or deletions have been made correctly. If a developer disregards running the application when forced to do F5 Development the tendancy is to produce a lot of code, most likely not refactored or tested, during each run of the application. The list of reasons to not develop this way can get long pretty quick. A developer needs to be able to write a test, implement the code, and run the test without a framework launching the development fabric, or worse being forced to not write a test and running code that launches a whole development fabric framework.

Now don’t get me wrong, the development fabric is freaking AWESOME!! It is one of the things that really sets Windows Azure apart from other platforms and infrastructure models that one can develop to. But the level of work and effort makes effectively, cleanly, and intelligently unit testing code against Windows Azure with the development fabric almost impossible.

But with that context, I’m on a search to find some effective ways, with the current SDK limitations and frustrations, to write unit tests and encourage test driven design (TDD) or behaviour driven design (BDD) against Windows Azure, preferably using the SDK.

So far I’ve found the following methods of doing TDD against Windows Azure.

  • Don’t use the SDK. The easiest way to go TDD or BDD against Windows Azure and not being tightly bound to the SDK & Development Fabric is to ignore the SDK altogether and use regular service calls against the Windows Azure service end points. The problem with this however, is that it basically requires one rewrite all the things that the SDK wraps (albeit with better design principles). This is very time consuming but truly gives one absolute control over what they’re writing and also releases one from the issues/nuances that the Windows Azure SDK (1.3 comes to mind) has had.
  • Abstract, abstract, and abstract with a lock of stubbing, mocking, more stubbing, and some more abstractions underneath all of that to make sure the development fabric doesn’t kick off every time the tests are run.  I don’t want to abstract something just to fake, stub, or mock it.  The level of indirection needed gets a bit absurd because of the design issues with the SDK.  The big problem with this design process to move forward with TDD and BDD is that it requires the SDK to basically be rewritten as a whole virtual stubbed, faked, and mocked layer. Reminds me of many of the reasons the Entity Framework is so difficult to work with for testing (has the EF been cleaned up, opened up, and those nasty sealed classes removed yet??)

Now I’ll admit, sometimes I miss the obvious things and maybe there is a magic “build tests real easy right here” button for Windows Azure, but I haven’t found it.  I’d love to hear what else people are doing to enable good design principles around Windows Azure’s SDK. Any thoughts, ideas, or things I ought to try would be absolutely great – I’d love to read them. Please do comment!

My Current Windows Development Machine Software Stack

I recently did a clean install of Windows 7 64-bit.  It had been a really long time since I listed the current tools, SDKs, and frameworks that I’ve been using.  Thus here’s my entourage of software that I use on a regular basis that is installed on my primary development machines.

Basic Software & System OS

Administration Utilities

Themes & Such

In addition to these packages of software another as important, if not more important to my day-to-day software development includes these software services and cloud hosting services.

SaaS, PaaS, and IaaS

Software I will be adding to the stack within the next few days, weeks, and months.

Project Review, What Would You Want To Know?

I’ve worked more than a few projects in my career. One thing that I always find sorely missing throughout many Enterprises is a follow up report of what went well and what went wrong on a project. In other words a list of successes and a list of things to improve. With that in mind I’ve put together the following survey questionnaire for the end of a project. What other items might you add that you’d want to know?

  1. Is the overall project considered a success?
  2. What caused roadblocks or stoppages during the project?
  3. What caused excess work that was unnecessary?
  4. What processes could be avoided, added, or otherwise changed to streamline the day to day development and operations?
  5. What could management do to have made the project even easier to accomplish successfully?
  6. What could inidividual developers do to have made the project even easier to accomplish successfully?
  7. Were the tools needed to complete the project made easily available?
  8. Were access, work environment, and other physical assets provided in a timely manner to complete the project?

Please leave a comment or three about what you’d want to find out once a project is complete.

It Brought a Tear to My Eye, Agile Ideals Rock!

I’ve been leading a software development project for a little over a month, one of my team members and I have been communicating back and forth steadily.  Via IM or verbally, e-mail or however we need to.  We’re having a good time figuring out things as they come and getting things done in a very Agile way.  To lay it out as the manifesto is written;

We keep ourselves and interactions over process and tools.  We make sure to have working software on almost every single build that could literally be deployed, while forgoing the currently unnecessary documentation.  We collaborate constantly with the customer representative and don’t worry every minute about the contract negotiation.  Response to change is almost instant, as it comes along almost every day.

As we’re hustling along getting a complete vertical implementation of a project together this coworker comes to me and states, “It is great to work on a project with someone that knows what they’re doing, and not sent off in a corner to read documentation books on what was done in the past!”  That statement made me so happy.  This is one of the major reasons I advocate Agile!

Agile helps team members get bought into the project.  The team gets involved in ways that other processes just don’t allow.  The team feels enabled, empowered, or whatever one may call it to actually get the job done!  Being Agile isn’t about process or tasks or work items, being Agile is a mindset, is about being interested and involved in what you’re doing for your project.

After a dirge of conversations and some frustrating efforts recently, this is the type of thing that leaves those negatives in the dust.  This is the type of statement and motivation, when I see it, that makes me love what I do and love to come into the office each day!

So anyway, I had to make this post.  Because today, even though I thought it would be a slightly miserable day.  That one statement redeemed it and my day is now rocking!