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