Still pumped up with the positive energy of the dinner with the rest of speakers the day before I walked the short stretch under the rain to be poetically showered in knowledge of the them of the day: testing.

Effective Specifications and Tests for Agile Projects

I kind of liked the presenting style: writing your own slides on a piece of paper as you go. A few highlights: recognizing that different specifications/tests apply to different phases of a feature; the picture of a piece of documentation disguised as a Titanic ready to crash against the iceberg that represents its update; and the need of express integration test in business terms instead of testing (or UI) terms.

Pretty nice and easy way to start a day if you ask me.

Winning Big with Specification by Example. Lessons Learned from Successful Projects

I mentioned I was content with the previous session being completely theoretical, but I expected some meat in this one. The fact that I did not get any left me a bit disappointed. The session was introduced as a “proof” of why executable specifications work. Either that statement was a bit too bold or I did not get the message at all.
As a matter of fact I took very few notes but two “lessons” stand out: do not translate specification tests into another language (be it unit test or UI jargon) and get some help from the Business Analysts when writing tests but do not let them write them alone.

Kill your ORM

I really like Rob Conery. He is really funny and laid back, but very thoughtful at the very same time. Our opinions collide quite often, more often since he “saw the Ruby light”, and yet I keep returning to listen him speaking.

This time it was to talk about the data access in general and ORMs in particular. I think his ideas of presenting the recent history of Data Access though his experiences in a timeline with a “decade” theming was simply genius: ADO is the happy 50s/60s when everything was so simple; ADO.NET is the crazy 70s; .NET 2.0 and code-less data-sources is provocative 80s, the 90s comes with ORMs and and angry generation X developers; whereas the new millennium is ruled by LINQ.

If you think that was good, I will spoil some of his pearls: “Data access is drama”, “EF gets you to Vietnam even faster” and “Damn You Skeet… do not even look at my code”.

As  much as I truly enjoyed the talk I could not but disagree that having SQL all over the place is nice, no matter how much dynamic voodoo you throw at it. It’s nice and simple for simplistic query scenarios, but good luck trying to update a complex object graph with that simplistic approach. There you have your excuse to use ORMs. And for the simple parts… use whatever you want. Who said that you can only use one and only one data access strategy?

Quality without Testing!!

My good moods became darker pretty soon. I promised not to bitch but I have to be very critic with this talk.

I had never rated a session previously with a negative grade. This was my first and I felt my vote was not red enough. Had I not been in a difficult seat to get out of the room I would have left 10 minutes into the talk.

Seriously, it was such an epic fail: the delivery was terrible, the speaker was anything but engaging, the content not present and on top of that the session ended almost half-an-hour before the due time.

One simply cannot have a catchy and provocative title and end the session stating exactly the opposite of the abstract. Should not be allowed. I will save this pearl: “Ends are problems and means are solutions”

TDD as if You Meant It

A late change of plans and the fact that there was no abstract available made me come to this one without a laptop. But not everything was lost. Not having a laptop made me into pairing with a guy I met the day before. We paired using his Mac (God, I hate the keyboard) and… Javascript!!! One can tell a real javascript programmer from me by the number of typos he makes and the number of times he tries to auto-complete with tab

The experience was exceptionally positive and we managed to have a working design using the technique proposed by the speaker. It was pretty weird, but ping-ponging and letting the navigator (the guy not with the keyboard) watch for rules breakages worked surprisingly well, not that I am likely to use this technique as I felt that thinking a bit before hand helps me better that pounding the keyboard like a madman.

Dealing with Defects on an Agile Team

I was looking forward for this session as it is a very current issue within my team.

I really liked the ideas: “zero tolerance to bugs”, “bugs are a hidden backlog”, “shorten the feed-back loop as much as possible by having involved and co-located testers” and “the best bug list is no bug list”.

I was kind of disappointed, not with the session (which I enjoyed greatly) but with the fact that the solutions offered are not applicable short term to my team. But was comforted by the fact that we are doing the second best we can do to plan for bug-fixing.

Best Practices for Writing First Class Unit Tests

I has been a long day, with ups and downs and my tired brain looked for the comfort of familiar territory. Not that I learned anything new on the subject but it was not a bad session at all and unit testing newcomers could receive some useful advice. One of my favorites: “if it is not important for the test, it is important to hide it”.