Rainsberger's workshop at Helsinki Oct 2011

I have visited the workshop of J.B.Rainsberger at our Finnish headquarters. It was very interesting for me and I have got a lot of very useful information about TDD. During whole workshop Joe made some online notes and because he told us that he would remove them after a month I have decided to save them below

Coding

• https://github.com/jbrains/TddAndBeyond-Helsinki-2011
• https://github.com/jbrains/PointOfSale-Python

Reading

• http://c2.com/cgi/wiki?TestDrivenDevelopment
• http://blog.palantir.com/2007/11/06/writing-junit-tests-for-memory-leaks/
• http://c2.com/cgi/wiki?CouplingAndCohesion
• http://agileinaflash.blogspot.com/2009/03/arrange-act-assert.html
• http://code.google.com/p/openspacecode/wiki/TddAsIfYouMeantIt
• http://www.artima.com/intv/metadataP.html
• http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1319454159&sr=8-1
• http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
• http://c2.com/cgi/wiki?FeatureEnvySmell
• https://groups.google.com/forum/#!topic/growing-object-oriented-software/dOmOIafFDcI
• http://www.atomicobject.com/files/PresenterFirstAgile2006.pdf
• http://blog.thecodewhisperer.com/2011/06/22/adding-behavior-with-confidence/
• http://www.jbrains.ca/permalink/becoming-an-accomplished-software-designer
• http://c2.com/cgi/wiki?RidiculousSimplicityGivesRidiculousResources
• http://stevef.truemesh.com/archives/000194.html
• http://www.jbrains.ca/permalink/how-test-driven-development-works-and-more
• http://www.jbrains.ca/permalink/becoming-an-accomplished-software-designer

Concepts

• Put tests in a separate namespace, so that tests use the same interface that production clients use.
• Which test will force me to write the code that I think I need to write? This helps me avoid writing unnecessary code.
• Start each test with the thing you want to check. (Write the assertion first.)
• Run as many tests as possible as often as possible. Automate running tests to every time you press Save, if you can.
• Check one thing at a time. ((One assertion per test or one expectation per test) and one action per test.)
• Cutting code (or text) is dangerous. Instead: copy, paste, get the new copy working, then delete the old copy.
• Abstractions in code, details in data. Dependency Inversion Principle. Move duplicated data from the production into the tests. Move duplication from the supplier towards the client.
• Move code that validates input up the call stack towards the caller. Check data very thoroughly at the system boundary.
• Stub queries; but expect actions.
• Three Strikes and You Refactor; three copies is enough to remove duplication (two copies might not be)
• Make the weakest assumptions possible.
• When you mock an object, you are testing its clients.
• When you think you want to change something, but you're not sure how to change it, write more tests (add a new feature).
• If you can't invert a dependency, at least make it explicit (obvious).