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 <[email protected]>
> 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 <[email protected]>
>
>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
