Tuesday, May 13, 2014

FitNesse is NOT a Replacement for Fit

In my experience FitNesse has turned out to be more of an obstacle to productivity than a boost.

I have used FitNesse on numerous projects over the past few years and have come to the conclusion that FitNesse, not Fit, is more of an obstacle to my productivity than a boost especially as projects get larger and more complex.

Here are the main reasons for why I think this is so:
  1. It runs contrary to the original notion in Fit that separates the Client and QA from the development team.This was the central idea of Fit as envisioned by Ward Cunningham.
  2. The built-in editor in FitNesse is useless for anything more than a single page of source and there is no hook to link to your own editor. It is next to impossible to perform any kind of minimal modern editing tasks like search/replace across multiple tests.
  3. There are too many fixture types confusing the test writer and irritating the developers.

Fit, the original Framework for Integrated Testing, had the right idea:
  1. The Fit test author (customers, managers and QA) can use the application of their choice (Word for example) to create the HTML test document.
  2. The Fit test authors are in charge of organizing and maintaining the test documents, not the developers.
  3. Separate the Client/QA from the developers (that's a good thing, if QA cooperates too much with developers a dangerous trust can develop).
  4. Developers are responsible for implementing only a few, if any, specialized fixtures.
Unfortunately Fit has been eclipsed recently by FitNesse and as a result has lost it's initial appeal and purpose.

To prove this I am switching to Html/Fit in my own development work and will try my best to separate dev from the QA role as much as possible. The idea is to use an HTML editor like Word or Avaya to maintain the test docs and only test the public API from the client point of view.

FitNesse, and especially Slim, still serve a useful function for development work as an extended unit test framework for testing basic end-to-end scenarios that are not generally unit-testable and development teams should leverage FitNesse as necessary within their team.

Thursday, May 23, 2013

I love writing code!

Ever since my first exposure to programming in 1973 I was hooked. I have not stopped since then. I even got a degree in Computer Science to make it official.

I still enjoy it every day. I get up in the early morning hours and pick a project to dive into. Whether learning a new technology, fixing bugs in my products, adding features or just tweaking my build procedures I enjoy the process. I think that is the key: I am addicted to the automated process of software development.

Anyway this is my Software Development blog where I hope to cover what I have learned, and am continuing to learn, over the years in regard to the software development process and best practices as an individual programmer. The key word here is individual. I am not collaborating with anyone on these projects. I enjoy it purely as a personal pursuit and there-in lies the challenge:

How can I, as an individual developer, maintain a suite of software products in a constantly changing environment of platforms and languages?

This blog addresses that question. Should be fun.