As for me, the StringCalculator kata is a very good (or better to say nearly perfect) demo of a classic TDD approach: small and fast steps, live objects… really nice!
Though I see (feel?) some issues… mostly about factoring-out new classes without tests (yes, that was refactoring… but still), I believe, that's beyond classic approach and only top-down TDD with mocks may help to keep TDD pure here. (I've scheduled a task for detailed exploration of how mocks can be used here to provide "seamless" TDD in this case.) So, this screencast is a great lesson on TDD in Smalltalk. -- Best regards, Dennis Schetinin 2013/6/7 Rafael Luque <[email protected]> > Hi Dennis, > > What do you think about the approach shown in this screencast: > http://www.pharocasts.com/2011/02/stringcalculator-kata.html ? > > I'm far away from being an Smalltalk developer, but I tried to show a TDD > process to solve this simple kata. > > Rafael Luque > > > 2013/6/7 Dennis Schetinin <[email protected]> > >> I don't remember exactly where and when, but I think we've discussed the >> Laser Game tutorial already. I told this before, and I (after reviewing the >> tutorial again) should repeat it again: actually, this tutorial doesn't >> show TDD. I can explain my opinion in detail if someone's interested, but >> in general, that's simply an up-front design approach with some automatic >> testing. It's not even "Test-First" approach most of time. >> >> Disclaimer: I don't mean the tutorial and/or the design approach used >> there are bad. I like this tutorial. It's really very good: it shows many >> aspects for Smalltalk programing, it shows how to use debugger and >> inspectors properly. I borrowed many ideas from there for my Smalltalk >> programming course… It's just not TDD, not "pure" TDD at least. >> >> >> >> -- >> >> Best regards, >> >> >> Dennis Schetinin >> >> >> 2013/6/7 <[email protected]> >> >> Paul Davidowitz wrote: >>> >>>> It seems to me that a big reason for developing via writing tests first >>>> (Test Driven Development) is that the tests serve as a debugging tool -- >>>> if a test breaks, then the last piece of (non-test) code that change is >>>> likely the culprit. But with the powerful debugging environment that >>>> comes with Smalltalk, I am wondering of the utility of TDD (TDD is big >>>> in the Ruby camp perhaps for a reason). After all, writing and >>>> re-writing the tests becomes quite a non-trivial chore (not to mention >>>> that the tests themselves could be buggy). So my question: Is it ok in >>>> Smalltalk to write tests afterwards? Is it even perhaps recommended? >>>> >>>> - Paul >>>> >>>> >>>> >>>> >>> Actually some Smalltalk'ers consider the debugger a major facilitator of >>> TDD by mostly coding from within the debugger. >>> 1. Before writing any application code, write a test. >>> 2. Execute that test straight away. Of course it fails because you >>> haven't written any application code. >>> 3. Up comes the debugger - now "from within the debugger" add the >>> application code needed to satisfy the test. >>> 4. Repeat. >>> >>> A good demonstration of this is Stephan Wessels' Laser Game tutorial [1] >>> (but you'll temporarily need to revert to Squeak 3.9 to do it) >>> cheers -ben >>> >>> >>> >> >
