One question that often pops up when talking about TDD is how to test frontend code. Some say just don’t. I don't think that's particularly helpful though. So this article will look at perhaps the most commonly raised objection to TDD in frontend code. How to deal with the GUI.

But first I want to dispel a common misconception about TDD. TDD is not about providing a complete set of regression tests for the application. It's actually not that much about testing, in terms of what testers do, at all. In TDD we use tests to drive the code and design. The actual testing, such as testers care about, is a side effect of this process. Just as regression tests or regression checking is a side effect. This also means that we are allowed to take some shortcuts in terms of coverage to make the code we want to drive with tests testable.

The title is a quote from Kent Beck. I'm still reading that book I keep going on about. The one that's not a book but will become three. Tidy First? (do subscribe and read his words, not mine). Where he states this. Something that should be quite obvious really. But isn't, it seams, to many.

So, what relationships are we talking about? And how is software design an exercise in said relationships?

I'm still reading Kent Beck's new book (not quite a book but something not far off) called Tidy First?. Being a late subscriber and all there is a lot to read. And now I stumbled over a chapter on untangling behaviour changes from tidyings. The idea is, and I agree fully, that we don't want to mix changes in behaviour and changes in structure. But we all now how hard that can be. We start to do some behaviour change just to realise we just made a bunch of small structural changes to allow for the original change.

Then comes the question, how do we untangle the two? Or do we even try? Naturally there are situations where it's worth untangling, just as there are to not bother. But most of the time we'd like to not have to do either.

I was reading Kent Beck's new book (not quite a book but something not far off) called Tidy First? and a paragraph in in the chapter tl;dr Cohesion caught my attention. Kent Beck writes:

It can be difficult to see how to de-couple elements. Increasing cohesion, on the other hand, is easier to imagine.

People have tried to define programming since forever. Is it art, engineering, or perhaps craft? It may be that it's all, or neither. I tend to think about it more like gardening than craft or engineering or art. This is because software tend to take on a life of its own over time. This may sound a bit odd to some. But think about it a bit. Perhaps it will start to make sense.

As we work on a piece of software over time there are usually several different people who work on it (even if that's several incarnations of you). Each different author add their own thoughts and directions to the software. With some skill the people working on it will be able to keep it together enough that everyone feels at home. But for each incarnation of the software it changes a bit.