Rethinking Automated Testing

While you’ve been worrying about your BDD adverbs the iFart dev just made $40,000.

- Iain Hunter

Can you give 140 char synopsis of "opportunity cost of TDD?"

Is #TDD always a "Best Practice"? Is there even any such thing? When shouldn't you use it? What could you do instead?

- Conversation on Twitter

Testing implementation is terrible terrible terrible.

- Matt Rogish

The pendulum is swinging back and forth in the TDD and developer-testing world...
I blogged over two years ago about Testing Backlash and then again one year ago Are you too agile for TDD/BDD?

It seems the time has come for the pendulum to swing by once again. In an almost mystical conjunction a lot of alpha geeks are voicing current "new" insights about automated testing and TDD.

Maybe this is the developer community climbing the ladder to another stage of competence or to another stage of grief (the viewpoint is probably depending of the pains in your current project)… but maybe it is just that alpha-geeks like any other intelligent beings are getting bored after a while and turn to new topics.

Anyways, here is a list of the recent tide of "let's rethink automated testing":

• Michael Feathers: Taking Automated Tests Off The Pedestal
• DHH: Testing like the TSA
• Scott Bellware: The Inflection Point - How Long can you Safely Avoid Automated Testing
• Alberto Gutierrez: The evil unit test.
• Dan North: The Art of Misdirection: The opportunity cost of TDD (or in the NDC Magazine)

Just for completion I am reenumerating older reflections on the topic:

• The Dark Side Beckons? by Obie Fernandez
• Test-Driven Development and Embracing Failure by Steve Freeman
• Problems with TDD an Essay by Andrew Dalke. Heavily discussed on his blog and on Hacker News.
• Ayende's posts: Even tests has got to justify themselves and re: Are you smart enough to do without TDD
• And finally Luce Francis brilliant presentation: Testing is Overrated (matching blog post, slides)

Update:
Tudor shows in When testing does not cut it that testing is not always the best alternative to ensure certain properties of a software system.

If you like this, follow me on twitter ...

Thoughts about Dependency Injection

I just discovered, that a quote of me made it to the cover of Dependency Injection in .NET:

Looking at the book in its final form, I am surprised at how well that quote fits my current thoughts.

I like the style of the author. This stackoverflow answer is just a nice example of his style: dependency injection can be dangerous for your career.


A quote from my original review of the manuscript:

This is one of the best programming books I have read in the last three years. I like about everything in this book. The technical insights. The way  it focuses on concepts and not on tools or technologies. [...] It is definitely suited for programmers that want to learn good design and development techniques. It is not a reference book for a technical framework.

However I have a problem with the hype of dependency injection in general. It definitely goes into the direction of accidental complexity. I mean 584 pages, is a bit heavy for a promise to get better internal quality ... given I do everything else right. Especially compared to other, much wider topics that can have a much broader impact on your development:

From this perspective "All you need to know ... and more!" fits quite well: You will learn a lot reading the book, but it is sad that the current state of software development is that loaded with accidental complexity so that you have to be concerned with that much non-essential overhead ...

I also recommend reading a real critique of the current state of dependency injection: "Dependency Injection" Considered Harmful

If you like this, follow me on twitter ...

The future smells like JavaScript

Of course I am only repeating what others are preaching about the recent rise of JavaScript.

But I think the movement is significant and can't be overstated. And recent developments are really even making it more and more interesting.

Nobody can deny hat JavaScript is the de facto programming language of Html5. Every other language trying to bolt itself onto Html5 looks like pure friction so far. And Html5 is looking upon a prospering future.

Today we are used to some established JavaScript frameworks that make working with JavaScript more fun and productive. jQuery seems to emerge as the clear leader by popularity here.

More recently tons of javascript application frameworks (so called MVC frameworks) are emerging, that facilitate programming complex applications inside the browser and taking most of the traditional presentation-logic away from the server.

On the other hand we have the node.js ecosystem that takes JavaScript to the server and allows us to use the same language, concepts, libraries and tools for the full application development stack.
And that ecosystem is thriving! JavaScript is the most popular langage on GitHub ... and have a look at the impressive node modules list.

Now this is all well and alpha-geeky, but there are showing up the first "real-world" success stories: Voxer, Walmart, LinkedIn ...

Of course there are the critics.

Surprisingly Microsoft recently positioned itself to become one of the most influencing conveyor of the JavaScript hype. It seems that they are investing heavily into JavaScript on different frontiers:

Microsoft was pushing node.js onto the the Windows environment.
Now they are pushing it into their Azure cloud platform. And evolving a 3rd party ecosystem around that.

But probably the biggest step for the future of JavaScript is the new strategy of Microsoft for Windows 8 desktop and tablet applications (Metro style apps). While there are several options for developing Metro style apps, JavaScript seems to become a major pillar.
This move opens up yet another area for JavaScript and JavaScript developers, completely adjacent to the web.
Developing for the desktop (or tablet) will most likely always be pretty different than for the web. For Metro style apps there will be a lot of new concepts, libraries and tools that are different to the ones that are used in web development (just have a look at WinRT, WinJS ...).
But the desktop- and the web-stack will move closer together and JavaScript with HTML5 and CSS will be the common denominator. Which I think is a very interesting evolution.
For instance look at this example of a drum sequencer (a traditional client application) that is using JavaScript and jQuery for its UI.
The prospect of reusing code and knowhow between desktop-ui- and web-ui-programming seems tempting ... even if a lot of .NET developers and other gurus are not so thrilled by the prospect of omnipresent JavaScript.

Of course another interesting thing will be to see how Metro style apps will change the architecture of future desktop applications. I think some concepts from web development will get adopted into desktop development. A stricter enforcement of separation between UI- and backend-components within a single application will most probably be a result (i.e. there seems to be no notion of traditional data-access in WinRT).

PS: This is my first cross-post between my blog and planetgeek.ch. Thanks @danielmarbach for inviting me.

If you like this, follow me on twitter ...

Vacation Books and Screencasts

I am looking forward to spend another vacation mostly under water.

For the travel and the time above the water I am filling my Kindle and my iPad with the following material:

Thanks to bertolami, mbaumeler and j_graber for the recommendations.

Presentation: Can JavaScript be elegant?

Last month I was invited again to speak at the SBB Developer Day 2011. Here is the presentation I held about JavaScript:

 

Kann JavaScript elegant sein?

View more presentations from jbandi

I enjoyed the event very much, and I hope to be invited again next time.

Opinions: Scala

Can you spot the difference:

Scala is a serious option for organizations developing on a JVM platform.

- Martin Fowler

 

 

The friction and complexity that comes with using Scala instead of Java isn't offset by enough productivity benefit or reduction of maintenance burden for it to make sense as our default language.

- Yammer moving from Scala to Java

 

If you like this, follow me on twitter ...

Model, model thou art my riddle!

Can you spot the difference:

In a Model View Controller application, you only ever want to see SQL code in the model.

-  Rails Receipes

The domain model should be independent of persistence implementation details.

- Domain Driven Design and Development In Practice

Probably we should accept that models come in different flavors...

... or maybe the grand master was right:

Using C means that people [...] don't screw things up with any idiotic "object model" crap.

- Linus Torwalds

If you like this, follow me on twitter ...