The course will be done in a practical manner. There is no room for comprehensive, one size fits all ideologies. Hence this workshop is not yet another UML promotion event. Rather it teaches a very eclectic, battle proven, hands-on approach to software design. The primary goal of which is to give developers a thinking tool to enable them to develop solutions in their heads, quickly visualize them for themselves and others, and in the end easily translate them into clean code.
Clean code means testable code. To make code testable it’s helpful to, well, start coding with tests. That’s what TDD always was about.
Unfortunately, TDD is hard to get right. Maybe all that’s important has already been said by Kent Beck in “TDD by Example” – but what does it really mean? TDD as traditionally taught seems to be simple, but in the end it’s not.
This workshop thus takes a different approach to test-driven coding. It builds on the traditional red-green-refactor cycle but offers different ways to deal with different situations. Two more gears are added to the only one of original TDD. Attendees learn to shift through those gears depending on how well they are progressing.
What differentiates the gears is what’s done in the green phase of TDD:
” 1st gear: Decompose the production code into smaller problems before writing any logic – or “Informed TDD” by Ralf Westphal
” 2nd gear: Inline production code with tests – or “TDD as if you meant it” by Keith Braithwaite
” 3rd gear: Implement production code in a KISS way – or original TDD by Kent Beck
Which TDD gear to drive coding in is a matter of clarity: How well is the problem understood? How well has a solution been modeled? How deep is the experience with required technologies?
Lower gears are for more difficult situations. The workshop thus adds two gears below the original TDD mode. This is done based on the insight, that coding production logic often is started too early and the refactoring step is skipped all too often. With the 1st and 2nd gear refactoring becomes less of a burden or unavoidable and easy.
And on top of that: Attendees will learn to not paint themselves into a corner with tests. Tests must not become a girdle and later strangle refactoring efforts. There will be a clear distinction between maturity tests (“Is the code already correct?”) and regression tests (“Is the code still correct?”).
Automated tests are too important to be a burden. It’s the mission of the workshop to make testing a worthwhile and pleasurable activity for every developer.
Target audience: Developers, software architects.
Learning methods: Practical exercise, independent work.
Assesment methods: Execution of independent work.
Assesment form: Independent practical tasks on relevant topics.
Price includes coffee breaks and lunch in restaurant Lusikas.
More information here