Re: [Pharo-dev] Necessity of TDD with Smalltalk

[btc]

Dennis Schetinin wrote: I don't remember exactly where and when, but I think we've discussed the Laser Game tutorial already. It was probably me.  I _really_ like it.  It was one of the things that hooked me in to Smalltalk.  However this was right when I was starting out Smalltalk, so I had a lot more occupying my attention than discriminating the shades of TDD,  so I guess I've carried a misconception of the definition since.   Thanks for your perspective. cheers -ben 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