Dennis, It would be great to receive your ideas about how to use mocks in this case. Feel free to add any comment directly in the screencast at Vimeo (http://vimeo.com/19591202)
Thank you! 2013/6/7 Dennis Schetinin <chae...@gmail.com> > 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 <rafael.luque.le...@gmail.com> > >> 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 <chae...@gmail.com> >> >>> 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 <b...@openinworld.com> >>> >>> 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 >>>> >>>> >>>> >>> >> >
