Last talk of the last day at Øredev 2009. I listened to "What not to test" by Robert Sabourin. 

I like testing because I am fortunate enough to belong to a school of programming that wants to do things the right way. So naturally I was intrigued by the theme of the talk. Isn't testing Always Good?

After listening to the talk I still believe this to be the case. However, there might be situations in your career when this will be unfeasible for some reason or another. In this situation knowing what not to test is far superior to skipping a test you didn't know you had to do!

Knowing what not to test comes from knowing as much as possible about what to do test. To this end, Robert advocates continuously collecting testing ideas - on all levels possible. Study how to attack systems and get ideas for testing. Study how your application will be used by users (as opposed to knowing just what the application does for the users). Study specifications and try turning them upside down for alternative usage scenarios that you might have be unaware of.

Look at performance, capabilities, environments, failure models. Become aware of stress levels and state changes.

And so on judgment day you and your application will not be unprepared.

This concludes the blogging from Øredev sessions. Now, with all the great ideas, knowledge, and inspiration, there's only one thing left to do; become a better developer!

Good luck and see you next year.

Was hanging out at the gourmet coffee bar on the side of the exhibition floor.  For the past three years Øredev has asked Johan & Nystrom to set up shop here for everyone to enjoy (what? developers like coffee?). The guy behind the bar is Mattias Sjöbäck, the Manager for Southern Sweden for Johan & Nystrom – a rather special kind of coffee company.  And their elixir, served by heroes of the craft (yes, only an artist can foam like that) is incredibly delicious.  I was walking around like an idiot saying “I think this is the best I’ve ever had.  I think this is the best I ever had.” 

The company is a specialty roasterie (sp?) that actually goes and visits each of the farms from which they purchase.  They do this for quality assurance, but also to make sure the farm is operated in a socially responsible manner.  That way they can deal directly with the farm allowing it receive an even better deal than certified fair trade. 

But I think that’s not the best thing that is making a stop at the Øredev branch of Johan & Nystrom cool:  Mattias and his partners consider themselves coffee geeks analogous to the techie geeks gathered at Øredev.  Of course they don’t know what any of the tech talk is about so the conversations that happen while they make your cappuccino slide over to the more personal.  It’s a spot in the Øredev mix of talking, listening, sharing, where we’re just plain hanging out with new people – over the best coffee you’ve ever had.

Is Behavior-Driven Development just syntactic sugar for integration testing? That's the question I have been asking more than once recently. There's RSpec, and there's Cucumber - if you are a Ruby developer you'd have heard about those. But why should you do BDD? Because BDD tests cover something Unit Tests don't? That's not the case - in terms of code coverage, BDD doesn't add anything.

(Take a Rails application for example. You can test model integrity with unit tests; application logic with functional tests; and user-app interaction flow with integration tests. That's complete coverage).

Having these doubts about BDD I was eager to sit in on the Cucumber session with Aslak Hellesöy. Things were a bit more involved than I thought. Firstly, it became obvious that Cucumber (or Gharkin, the DSL that powers it) parses human-readable text into strings into which regular expressions can be inserted at runtime.

(Ample amounts of human-readable text is what flashes in the eye when first viewing BDD code. It's easy to think of BDD as something only non-techies can read, but there's more to the picture).

Another interesting detail is that Cucumber follows a well-defined convention for testing. You are Given something, and When you do something else Then something third happens. That's a nice coupling of syntax and semantics. Function follows form. Otherwise it'd be easy to get an impression that nearly everything goes into a Cucumber test spec.

Upon asking Aslak what exactly is Cucumber for: is it mainly for stakeholder - developer communication or is it a superior testing tool aimed at the developer, I received the following answer:

"Cucumber is a stakeholder-team communication tool designed to add more value to the client, however it is also a good developer tool that is capable of providing project documentation at all stages of development: before-coding, during-coding, and after-coding".

A good and exhaustive answer. Now, is Cucumber for you?

Friday, 6th of November 2009 at Øredev. The time had come to sit in on the one of the main attractions of the conference. A talk by the man to whom many of us developers owe their career. (If you have worked with Object Orientation and Model-View-Controller you belong in that category).

Trygve Reenskaug made a monumental talk about rethinking the foundations of Object-Oriented development that spanned the three "ages" of programming: its genesis, the difficult maturing stage, and the recent breakthrough at a higher level.

The first part, "Procedure Orientation: Success" detailed the dawn of programming discipline where chunking code for readability and testability were good practices. Developers used to review each others' code to find bugs; failing early was considered good. If this sounds like something you've heard before, you're right. Procedural programmers of the day were Agile by default. They found what worked and stuck to it.

The next stage ("Class Orientation: Collapse") was more complicated. By that time, it was decided that a program should model the real world by mirroring its objects. Accounts, Users, and Money were represented in classes that at runtime had certain behavior, roles, and responsibilities. This was a major cognitive breakthrough for developers, however it also resulted in a dangerous chasm. To stakeholders, the program was a dynamic system with a certain behavior. The implementors had to deal with a different picture: all this behavior had to be represented using primitives that were static in nature: classes, attributes, objects. Stakeholder - developer communication became complicated.

Enter the last stage ("True OO: a new beginning"); the revival of "true" Object-Oriented development. Now, we are back at what objects were SUPPOSED to do in the first place. An object is something that plays a role. And a role exists in a certain context. (Like acts in a theater play are contexts for roles?) That is crucial. Without context, everything is static. Add context, and everything comes alive; roles can be injected into objects at runtime (context is dynamic!). By now you're probably wondering what exactly these roles are - how do you code them?? While getting into the gory details seems to be overkill for this blog (and would do no justice to Trygve's talk), consider this: roles are something that can have methods!!

With this renaissance of Object Orientation, best practices suddenly shine again. Peer code reviews become meaningful, because now you'll be reviewing both the class AND its context! This is responsibility-driven design.

This has no doubt been of the most memorable sessions of Øredev. I'm glad I attended it  - otherwise I would have missed something that is crucial to the programming discipline and where it is going today.

Scott Handelsman led the day off today with a keynote that followed right along with the take-aways from Marc Lesser.  Going from taking the time to ask the important questions about what we want to avoid in life, and how to get more done by doing less, Scott started with that premise and offered everyday examples of what we can do about it.  He got us applying the lessons learned right down to how you manage your email account. 

Do it - Drop it - Delegate it - Defer it, man. Divest your psychic weight, dude

For a conference with efficiency and effectiveness as a theme this talk hit the bull’s-eye.  Now maybe we can finally get some stuff done.

Oh man, Ze Frank rocked last night.  What a fun, hilarious expedition through some of the simplest elements - fear and love in this case – that we recognize in each other even across something as complex as, errrr, well, the interne! His “work” seems inspired from anywhere and everywhere, but it’s also always real, and a collaboration with whoever wants to jump in. That guy brings an invitation to play in the purest form - best of all it's creative, but also smart and inspiringly human.  An earth sandwich?  Sweeeeet!