Re: [Pharo-dev] Necessity of TDD with Smalltalk
Paul 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?
Test-driven development works well when you have some idea of where you want to go. If you don't know yet what your first test could look like, the powerful debugging environment of Smalltalk allows you to do some fast experiments. Then you might want to switch to TDD, as there are two ideas in TDD that are not covered by having a good debugging environment: - don't write more code than you have tests for, so the design is really driven by the tests - the tests provide insurance that you'll notice when something breaks. Writing and re-writing tests is what helps you get to a simple design. Tests need refactoring and DRY just as much as other code. Stephan
I dont think a debugger can ever replace TDD for two reason a) Tests are faster way to find bugs that don't want to be found ;) b) Tests are more than debugging tools (A) If you have already created a large suite of tests then all it takes is to fire those tests and just wait for the result to come out. Much fastert than going one by one bug. Also I dont know if the same applies for smalltalk but when i was coding for python not all code was executed and so I did not see all the bugs my code contains. So I had to test the app myself in many diffirent ways and I quickly found out that writing tests was way faster in the long run. (B) tests also make sure that your code behaves the way you want to behave and produces the result you want to produce. It may not be a bug per se, just a weird behavior. They also set a design pattern for your code to follow in the future. Generally speaking I use TDD for long code or code that is going to be maintained in the long run and get larger and larger. I think in that scenario TDD really excells. TDD is very popular in python, its part of the main library cpython(unittesting.py) comes with and there is also a third party library called "Nose" that even offer more features. I think TDD helps you keep your sanity in the long run especially with big projects and complex code. Debuggers are more like microscopes while i see TDD more like Satelites on orbit. ;) -- 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.
TDD is not about tests (as a bug-finding/debugger tool) at all. And the anti-regression feature of TDD is just the secondary one. First of all, TDD is about structuring thinking/creation process. And "test" here is a tool that allows and makes developer to formalize requirements and to translate them to the language they will be implemented in. This starts and really drives coding. Thus, a programmer that really masters TDD (really means an ability to apply "pure" TDD for all programming activities: both top-down and bottom-up design activities) is expected to produce much better architecture/design/code. ⦠So, I don't think TDD is somehow obsolete by Smalltalk. Vice versa, TDD should be really efficient here. And it's a great pity TDD is not actually popular in Smalltalk society. One of the dire consequences is that modern Smalltalk environments are not "TDD-oriented" and don't advantage from good TDD methodology. ⦠Yea, that's just one of my pet peeves :) -- Best regards, Dennis Schetinin 2013/6/6 kilon <thekilon@yahoo.co.uk>
I dont think a debugger can ever replace TDD for two reason
a) Tests are faster way to find bugs that don't want to be found ;)
b) Tests are more than debugging tools
(A) If you have already created a large suite of tests then all it takes is to fire those tests and just wait for the result to come out. Much fastert than going one by one bug. Also I dont know if the same applies for smalltalk but when i was coding for python not all code was executed and so I did not see all the bugs my code contains. So I had to test the app myself in many diffirent ways and I quickly found out that writing tests was way faster in the long run.
(B) tests also make sure that your code behaves the way you want to behave and produces the result you want to produce. It may not be a bug per se, just a weird behavior. They also set a design pattern for your code to follow in the future.
Generally speaking I use TDD for long code or code that is going to be maintained in the long run and get larger and larger. I think in that scenario TDD really excells. TDD is very popular in python, its part of the main library cpython(unittesting.py) comes with and there is also a third party library called "Nose" that even offer more features.
I think TDD helps you keep your sanity in the long run especially with big projects and complex code.
Debuggers are more like microscopes while i see TDD more like Satelites on orbit. ;)
-- 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.
On 6 June 2013 14:44, Dennis Schetinin <chaetal@gmail.com> wrote:
TDD is not about tests (as a bug-finding/debugger tool) at all. And the anti-regression feature of TDD is just the secondary one.
First of all, TDD is about structuring thinking/creation process. And "test" here is a tool that allows and makes developer to formalize requirements and to translate them to the language they will be implemented in. This starts and really drives coding. Thus, a programmer that really masters TDD (really means an ability to apply "pure" TDD for all programming activities: both top-down and bottom-up design activities) is expected to produce much better architecture/design/code.
⦠So, I don't think TDD is somehow obsolete by Smalltalk. Vice versa, TDD should be really efficient here. And it's a great pity TDD is not actually popular in Smalltalk society. One of the dire consequences is that modern Smalltalk environments are not "TDD-oriented" and don't advantage from good TDD methodology.
Why do you think Smalltalk environments aren't "TDD oriented"? What would an IDE need to be TDD oriented? (I can think of something like Ruby's guard, which runs tests every time you save a file.) frank
I didn't mean to start a big discussion so I'm not ready to state or develop my vision right now fully and logically⦠But let's try to start little-by-little. Considering Pharo as an example⦠there are few minor issues like lack of some code-producing features in debugger⦠the one I can remember right now is lack of code formatting there, but there are few more. Fixing such issues would be a first step towards TDD-oriented environment. Next steps would be about some more serious improvements: Test Runner improvements, auto-test running (it's already is implemented I think?), test annotations (expressing ideas behind every tests, relations between them, etc.), better test navigation and, perhaps, a "TDD-oriented" browser. Then, there should be introspection tools that for example silently save all the history and allow to review, analyze the development process regarding the idea-test-implementation triplets⦠â¦Sure, I rather have a "feeling" of the TDD-oriented environment then a good proposal right now. The feeling grows to something almost reasonable when I code, but I didn't have such chance for few months already, so I'm kinda caught off base :) -- Best regards, Dennis Schetinin 2013/6/6 Frank Shearar <frank.shearar@gmail.com>
On 6 June 2013 14:44, Dennis Schetinin <chaetal@gmail.com> wrote:
TDD is not about tests (as a bug-finding/debugger tool) at all. And the anti-regression feature of TDD is just the secondary one.
First of all, TDD is about structuring thinking/creation process. And "test" here is a tool that allows and makes developer to formalize requirements and to translate them to the language they will be implemented in. This starts and really drives coding. Thus, a programmer that really masters TDD (really means an ability to apply "pure" TDD for all programming activities: both top-down and bottom-up design activities) is expected to produce much better architecture/design/code.
⦠So, I don't think TDD is somehow obsolete by Smalltalk. Vice versa, TDD should be really efficient here. And it's a great pity TDD is not actually popular in Smalltalk society. One of the dire consequences is that modern Smalltalk environments are not "TDD-oriented" and don't advantage from good TDD methodology.
Why do you think Smalltalk environments aren't "TDD oriented"? What would an IDE need to be TDD oriented? (I can think of something like Ruby's guard, which runs tests every time you save a file.)
frank
⦠I've forgot to explicitly mention that TDD-ing in Pharo I spent most of time in debugger and inspectors: I see live objects there, I can investigate and find roots of troubles, I code there⦠That's why TDD is most productive in Smalltalk environment for me, and another reason why I think a good debugger (in an alive environment) doesn't make TDD unnecessary (or inversely) but rather complement and empower each other. -- Best regards, Dennis Schetinin 2013/6/6 Dennis Schetinin <chaetal@gmail.com>
I didn't mean to start a big discussion so I'm not ready to state or develop my vision right now fully and logically⦠But let's try to start little-by-little.
Considering Pharo as an example⦠there are few minor issues like lack of some code-producing features in debugger⦠the one I can remember right now is lack of code formatting there, but there are few more. Fixing such issues would be a first step towards TDD-oriented environment.
Next steps would be about some more serious improvements: Test Runner improvements, auto-test running (it's already is implemented I think?), test annotations (expressing ideas behind every tests, relations between them, etc.), better test navigation and, perhaps, a "TDD-oriented" browser. Then, there should be introspection tools that for example silently save all the history and allow to review, analyze the development process regarding the idea-test-implementation tripletsâ¦
â¦Sure, I rather have a "feeling" of the TDD-oriented environment then a good proposal right now. The feeling grows to something almost reasonable when I code, but I didn't have such chance for few months already, so I'm kinda caught off base :)
--
Best regards,
Dennis Schetinin
2013/6/6 Frank Shearar <frank.shearar@gmail.com>
On 6 June 2013 14:44, Dennis Schetinin <chaetal@gmail.com> wrote:
TDD is not about tests (as a bug-finding/debugger tool) at all. And the anti-regression feature of TDD is just the secondary one.
First of all, TDD is about structuring thinking/creation process. And "test" here is a tool that allows and makes developer to formalize requirements and to translate them to the language they will be implemented in. This starts and really drives coding. Thus, a programmer that really masters TDD (really means an ability to apply "pure" TDD for all programming activities: both top-down and bottom-up design activities) is expected to produce much better architecture/design/code.
⦠So, I don't think TDD is somehow obsolete by Smalltalk. Vice versa, TDD should be really efficient here. And it's a great pity TDD is not actually popular in Smalltalk society. One of the dire consequences is that modern Smalltalk environments are not "TDD-oriented" and don't advantage from good TDD methodology.
Why do you think Smalltalk environments aren't "TDD oriented"? What would an IDE need to be TDD oriented? (I can think of something like Ruby's guard, which runs tests every time you save a file.)
frank
⦠:) One more thing on the topic I've just remembered: a test shouldn't be just a method in a "test-case" class; test should be a separate alive object with its own state and probably extendable behavior⦠preferably a visible object that can be manipulated directly⦠Regarding this, I think SUnit was just a very first approach to a good TDD framework and should be rethought deeply (re-invented?)⦠but I don't know if someone ever tried to do that, everyone seems to be satisfied with test as methods approach. -- Best regards, Dennis Schetinin 2013/6/6 Dennis Schetinin <chaetal@gmail.com>
⦠I've forgot to explicitly mention that TDD-ing in Pharo I spent most of time in debugger and inspectors: I see live objects there, I can investigate and find roots of troubles, I code there⦠That's why TDD is most productive in Smalltalk environment for me, and another reason why I think a good debugger (in an alive environment) doesn't make TDD unnecessary (or inversely) but rather complement and empower each other.
--
Best regards,
Dennis Schetinin
2013/6/6 Dennis Schetinin <chaetal@gmail.com>
I didn't mean to start a big discussion so I'm not ready to state or develop my vision right now fully and logically⦠But let's try to start little-by-little.
Considering Pharo as an example⦠there are few minor issues like lack of some code-producing features in debugger⦠the one I can remember right now is lack of code formatting there, but there are few more. Fixing such issues would be a first step towards TDD-oriented environment.
Next steps would be about some more serious improvements: Test Runner improvements, auto-test running (it's already is implemented I think?), test annotations (expressing ideas behind every tests, relations between them, etc.), better test navigation and, perhaps, a "TDD-oriented" browser. Then, there should be introspection tools that for example silently save all the history and allow to review, analyze the development process regarding the idea-test-implementation tripletsâ¦
â¦Sure, I rather have a "feeling" of the TDD-oriented environment then a good proposal right now. The feeling grows to something almost reasonable when I code, but I didn't have such chance for few months already, so I'm kinda caught off base :)
--
Best regards,
Dennis Schetinin
2013/6/6 Frank Shearar <frank.shearar@gmail.com>
On 6 June 2013 14:44, Dennis Schetinin <chaetal@gmail.com> wrote:
TDD is not about tests (as a bug-finding/debugger tool) at all. And the anti-regression feature of TDD is just the secondary one.
First of all, TDD is about structuring thinking/creation process. And "test" here is a tool that allows and makes developer to formalize requirements and to translate them to the language they will be implemented in. This starts and really drives coding. Thus, a programmer that really masters TDD (really means an ability to apply "pure" TDD for all programming activities: both top-down and bottom-up design activities) is expected to produce much better architecture/design/code.
⦠So, I don't think TDD is somehow obsolete by Smalltalk. Vice versa, TDD should be really efficient here. And it's a great pity TDD is not actually popular in Smalltalk society. One of the dire consequences is that modern Smalltalk environments are not "TDD-oriented" and don't advantage from good TDD methodology.
Why do you think Smalltalk environments aren't "TDD oriented"? What would an IDE need to be TDD oriented? (I can think of something like Ruby's guard, which runs tests every time you save a file.)
frank
Dennis Schetinin wrote
Regarding this, I think SUnit was just a very first approach to a good TDD framework and should be rethought deeply (re-invented?)⦠but I don't know if someone ever tried to do that, everyone seems to be satisfied with test as methods approach.
+100. A TestCase class with test methods is an implementation detail. Writing them directly is like writing Smalltalk in bytecodes. This is exactly what I'm working on... would love some help ;) ----- Cheers, Sean -- 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.
What about sharing some details? I'll try to afford some time to take part, if you don't mind. -- Best regards, Dennis Schetinin 2013/6/6 Sean P. DeNigris <sean@clipperadams.com>
Dennis Schetinin wrote
Regarding this, I think SUnit was just a very first approach to a good TDD framework and should be rethought deeply (re-invented?)⦠but I don't know if someone ever tried to do that, everyone seems to be satisfied with test as methods approach.
+100. A TestCase class with test methods is an implementation detail. Writing them directly is like writing Smalltalk in bytecodes. This is exactly what I'm working on... would love some help ;)
----- Cheers, Sean -- 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.
Dennis: You seem to see more in TDD than most people. Can you write a small tutorial that illustrates what you think Smalltalkers need to see in TDD? I do think Smalltalk is missing something in it evolution. Thanks, Aik-Siong Koh -- 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.
I hope you are serious :) I don't know how to write a small tutorial, and I have no time to write a long one â¦Actually, I have been writing something like that (not for Smalltalkers but for my students) for a couple of years already⦠in Russian and really, really slow :( -- Best regards, Dennis Schetinin 2013/6/6 askoh <askoh@askoh.com>
Dennis:
You seem to see more in TDD than most people. Can you write a small tutorial that illustrates what you think Smalltalkers need to see in TDD? I do think Smalltalk is missing something in it evolution.
Thanks, Aik-Siong Koh
-- 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.
I absolutely agree that TDD is more related with the design process than simple testing. As "uncle Bob" wrote in his PPP book: "The act of writing a unit test is more an act of design than of verification." IMO a good dissertation about the true nature of TDD can be found here: http://www.drdobbs.com/tdd-is-about-design-not-testing/229218691 By other hand, another obvious difference between testing (not necessarily TDD) and debugging is that the first one can be easily automated, though debugging requires manual operation. Rafael Luque 2013/6/6 Dennis Schetinin <chaetal@gmail.com>
TDD is not about tests (as a bug-finding/debugger tool) at all. And the anti-regression feature of TDD is just the secondary one.
First of all, TDD is about structuring thinking/creation process. And "test" here is a tool that allows and makes developer to formalize requirements and to translate them to the language they will be implemented in. This starts and really drives coding. Thus, a programmer that really masters TDD (really means an ability to apply "pure" TDD for all programming activities: both top-down and bottom-up design activities) is expected to produce much better architecture/design/code.
⦠So, I don't think TDD is somehow obsolete by Smalltalk. Vice versa, TDD should be really efficient here. And it's a great pity TDD is not actually popular in Smalltalk society. One of the dire consequences is that modern Smalltalk environments are not "TDD-oriented" and don't advantage from good TDD methodology.
⦠Yea, that's just one of my pet peeves :)
--
Best regards,
Dennis Schetinin
2013/6/6 kilon <thekilon@yahoo.co.uk>
I dont think a debugger can ever replace TDD for two reason
a) Tests are faster way to find bugs that don't want to be found ;)
b) Tests are more than debugging tools
(A) If you have already created a large suite of tests then all it takes is to fire those tests and just wait for the result to come out. Much fastert than going one by one bug. Also I dont know if the same applies for smalltalk but when i was coding for python not all code was executed and so I did not see all the bugs my code contains. So I had to test the app myself in many diffirent ways and I quickly found out that writing tests was way faster in the long run.
(B) tests also make sure that your code behaves the way you want to behave and produces the result you want to produce. It may not be a bug per se, just a weird behavior. They also set a design pattern for your code to follow in the future.
Generally speaking I use TDD for long code or code that is going to be maintained in the long run and get larger and larger. I think in that scenario TDD really excells. TDD is very popular in python, its part of the main library cpython(unittesting.py) comes with and there is also a third party library called "Nose" that even offer more features.
I think TDD helps you keep your sanity in the long run especially with big projects and complex code.
Debuggers are more like microscopes while i see TDD more like Satelites on orbit. ;)
-- 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)
-
askoh -
Dennis Schetinin -
Frank Shearar -
kilon -
Rafael Luque -
Sean P. DeNigris -
Stephan Eggermont