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.leiva@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 <chaetal@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 <btc@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