I have no vimeo account needed to comment, so I'll answer here.

At 9:38 you are starting to move the parsing logic from StringCalculator to a (non-existent yet) Tokenizer. That's what mock objects are used for: simulate an object that is needed for a test but was not constructed yet. Thus, I would start with a test like the following:

StringCalculatorTests >> testUsesTokenizer

� � | calculator |

� � calculator := StringCalculator new.

� � [ :tokenizer | ��

� � � � calculator tokenizer: tokenizer.

� � � � [result := calculator add: '//;\n1;2'] should strictly satisfy: [tokenizer findTokens willReturn: #(1 2)].

� � � � result should be: 3.

� � ] runScenario

Then, I'd go exactly the same way: replacing the parsing logic with tokenizer call would make the new test green but break the testAddCustomDelimiter. Then I'll create the Tokenizer class, paste the logic there and make all the tests green.�

With this I'd still miss a unit test for Tokenizer, but I don't think it's a big issue as I don't have to design its logic here.

The testUsesTokenizer seems to duplicate the testAddCustomDelimiter, but actually is does not as it used for a different purpose and just shares a test case (I actually can use any other figures here just to be sure calculator properly uses the output of tokenizer).�

Best regards,

Dennis Schetinin

2013/6/7 Rafael Luque <rafael.luque.leiva@gmail.com>

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