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
Well, at one point, I realized that tests were saving my butt more often than not. Especially with Smalltalk. They also do form basic documentation for the lack of anything better. At least, you can debug them to see what happens. Phil On Thu, Jun 6, 2013 at 12:11 AM, Paul Davidowitz <pdavidow@fastmail.fm>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
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
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
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
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
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
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
I think the tests could provide valuable design feedback about the code under test, so it is good to have them. I can respond to those feedbacks effectively only when I'm writing them first, otherwise it might be too late. But this is a long topic. When I write tests first, I like the fact that the initial state of my test is red. So I can catch the point when it changes to green. If this happens when I expect, then I can be sure that I understand what is happening, and I managed to write a meaningful test. Writing tests afterwards makes easier to write tests which are always green. To avoid this I have to break the test after I finished it by changing something in the code. This is an extra step which I can save by writing tests first. -- View this message in context: http://forum.world.st/Pharo-dev-Necessity-of-TDD-with-Smalltalk-tp4691867p46... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
+1000 :-) -- Cheers, Peter. On 8 jun 2013, at 15:41, Attila Magyar <m.magyar3@gmail.com> wrote:
I think the tests could provide valuable design feedback about the code under test, so it is good to have them. I can respond to those feedbacks effectively only when I'm writing them first, otherwise it might be too late. But this is a long topic.
When I write tests first, I like the fact that the initial state of my test is red. So I can catch the point when it changes to green. If this happens when I expect, then I can be sure that I understand what is happening, and I managed to write a meaningful test. Writing tests afterwards makes easier to write tests which are always green. To avoid this I have to break the test after I finished it by changing something in the code. This is an extra step which I can save by writing tests first.
-- View this message in context: http://forum.world.st/Pharo-dev-Necessity-of-TDD-with-Smalltalk-tp4691867p46... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (7)
-
Attila Magyar -
btc＠openinworld.com -
Dennis Schetinin -
Paul Davidowitz -
Peter Hugosson-Miller -
phil＠highoctane.be -
Rafael Luque