What I liked:
  • context of GOOS and TDD
  • interactif walking skeleton
  • practical examples are nice
  • use of Ruby and RSpec
  • practical applicability
  • smoothness of the coding kata
  • live demo project -> even a coding-newbie understands!
  • no buzzwords or trends, functional and systems approach to what you test and xxxx
  • live demo
  • goed duidelijk GOOS uitgelegd
  • great session, a lot of information (to learn)
  • worked example
  • well prepared (UI mockup, diagrams etc)
  • having a reference (the book)
  • the 3 layers test/apprunner/testDriver
  • the demo!
  • explained concepts very well
  • good balance of theory + demonstration
  • great session on how to write your simple UI test for web apps (really great)
  • nice case and live programming
  • convincing demonstration
  • session format
  • nice example
  • sharing of experiences
  • working code
  • knowledge of the tools used
  • the topic
  • content is good
  • interactive
  • examples
  • interesting approach
  • great 30s presetnation
  • great beginning (3 styles of TDD) -> GOOS
  • practical insights
  • live coding + ruby
  • give me the will to re-read GOOS
  • explanations backed up by a successful handson coding session
  • well prepared
  • theory cleanly explained
  • coded something working
  • concept nice
  • kata
  • xxx interoduction + kata
To make it perfect:
  • the examples may be presented a bit faster
  • framework for swing application
  • what about backend-focused dev. usually xxxx other party builds a frontend. -> how to keep your xxx happy?
  • borelnootjes en bier ;-)
  • a little bit easier code sample, it was really fast
  • less time on explaining styles
  • clarify crucial concept (walking skeleton) early on
  • focus example on concept of working skeleton
  • better colors to be able to see the blue/purple (maybe best on a white background)
  • keep the naming in the code exactly in lin with the overview (auction-driver=test-driver)
  • a solution for swing applications!!
  • interactive part (but of course maybe not possible because of time limit)
  • introduction shorter
  • give an overview of good practices and experience
  • go a little further to demonstrate the whole end-to-end chain
  • need more time again!
  • consider more complex real life cases
  • make code more readable
  • speak both in small turns, to make it more living
  • post-it too little (unable to read from the end of the room)
  • choose a != example than from the booko
  • (sorry for falling asleep: too tired)
  • make a != between stubbing and mocking and faking (see xUnitPatterns)
  • example too simple tov real C++/C# appl
  • kata: less time on tdd (alread known) to focus more on the outside in approach, on the GUI-specific TDD (e.g. classes could have been written before). Example fo how product owners can write the GUI acceptance tests (tooling like selenium...)