ÖreDev day 4 – morning

· November 5, 2009

We’re of to a brand new day. Feel well rested although last night was quite late…

Keynote: What drives design?

This can be very interesting, if focus on the last two D in any [x]DD-technique (TDD, BDD etc). I’ll make a summary in the end.

This was a interesting historical overview to start with. Pretty cool that our industry is so young that the people who “started it all” are still not that old. Cool to hear about their troubles and stumbling on their way to greatness.

Rebecca Wirfs-Brock talked a lot about the RDD (responsibility driven design) and the patterns behind it. Then said compared it to other DD-techniques, such TDD, BDD, FDD and DDD and so forth.

Making the sausage

Now this should be interesting if by no other reason because of the speakers; Dan North, Neal Ford, Stuart Halloway and Tyler Jennings. They are going to talk about BDD in something called Clojure. It promise to be great!

It was a bit disappointing in a strange way; it’s was great but I had a hard time keeping up with their ideas. But after a while I get it but not well enough to re-loop it here. Sorry.

Functional languages are strange in itself and four functional programmers running through code they wrote a late night… You can probably understand my confusion.

Test-Driven Web UI Development

Scott Bellware is doing this. It’s the first time I’ll hear him, except in the local pub…

The talk was about lessons learned on trying to bridge the gap between testers and (TDD-)developers in an agile team.

Here are some random stuff that I picked up:

  • Selenium looks like a cool UI-automation testing framework. It free!
  • Selenium can actually generate test-code in a programming language of your choice. Beware that the tests are just a starting point – not the full blown test suite to use for ever and ever…
  • As programmers we shouldn’t do things that decreases productivity for the testers. It’s the whole teams productivity that counts.
  • The tests should describe the product not the implementation.
  • Good BDD-tests should be like a Table of Contents in a book. You don’t want to go into details if not needed.
  • Pair programming with a tester and a developer may be a way to find issues really quick. But I think a good, solid understanding of the test framework is needed.

I learned some about of Ruby and some on automating tests. I liked it but we didn’t reach all the way, sadly. James Bach had some comments that I would have loved to heard more around.

Twitter, Facebook