Fwd: Re: Proposal for Mock Objects at ESUG 2011
Hi all, I took the liberty of forwarding this mail to Tim Mackinnon and Steve Freeman, who invented the original Mock Objects. Here's Steve's answer. I'll forward further mails to this list. -------- Original Message -------- Subject: Re: [Esug-list] Proposal for Mock Objects at ESUG 2011 Date: Fri, 27 May 2011 09:25:30 +0100 From: Steve Freeman <steve@m3p.co.uk> To: Joseph Pelrine <jpelrine@metaprog.com> You should talk to Tim, he wrote a mocks library in about 3 classes (which is what it should take). He also has some interesting experience from the Kapital project that doesn't have unit tests. I hadn't realised that the ST world was behind in this respect. S. On 27 May 2011, at 05:41, Joseph Pelrine wrote:
FYI
-------- Original Message -------- Subject: [Esug-list] Proposal for Mock Objects at ESUG 2011 Date: Fri, 27 May 2011 08:36:27 +0400 From: Dennis Schetinin <chaetal@gmail.com> To: ESUG Mailing list <esug-list@lists.esug.org>
Hello!
I'd like to explore interest to Mock Object in Smalltalk society. I'm currently working on the topic, preparing a paper and presentation targeting at ESUG 2011.
I plan to present Mock Objects technique itself and a framework named Mocketry as a tool helping to apply it in practice. Of course I'll provide a small example to illustrate some of the ideas.
Apparently, Mocks technique is not popular tool among Smalltalkers. It even seems (to me), TDD is not as widely used as it could and should be (despite the fact it was born in Smalltalk). I have been using TDD and Mocks for many years in different projects with Smalltalk and other languages. Sometimes it was hard, sometimes I was even giving it up, but by now I think I have sufficient experience to state that TDD in general and Mock Objects specifically do deserve (at least) more attention by smalltalkers. Yes, Smalltalk is great language and it has great tools. This damps some aspects of the problems TDD and Mocks address, but for sure does not remove them totally. More than that, I can say I was most productive in Smalltalk when I used "classic TDD" and mocks in conjunction.
So, are other Smalltalkers interested in this topic? Do you think it worth to be presented at the conference? What are the problems you'd like to discuss there?
TIA
-- Dennis Schetinin <Attached Message Part.txt>
Steve Freeman Winner of the Agile Alliance Gordon Pask award 2006 Book: http://www.growing-object-oriented-software.com +44 (0) 797 179 4105 M3P Limited. http://www.m3p.co.uk Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ. Company registered in England & Wales. Number 03689627
Dear Dennis,
I'd like to explore interest to Mock Object in Smalltalk society. I'm currently working on the topic, preparing a paper and presentation targeting at ESUG 2011.
Sounds interesting. Steve Freeman (via Joseph Pelrine) wrote:
You should talk to Tim, he wrote a mocks library in about 3 classes (which is what it should take). He also has some interesting experience from the Kapital project that doesn't have unit tests.
Tim Mackinnon mentions mock objects in his talk 'Expressive Testing and Code for Free' at ESUG 2007 (report reachable from http://www.esug.org/Conferences). You remark
Apparently, Mocks technique is not popular tool among Smalltalkers.
and Steve, noting that, says
I hadn't realised that the ST world was behind in this respect.
I note that one or two who replied to your earlier post said they had not needed Mocks, or found them brittle, but I don't think the technique is _unpopular_ in Smalltalk. My own take is 1) Smalltalk's power means mocks are not needed as often. Many a time, you can get at what you need directly, or by use method wrappers to make the real objects (or the routes to them) act momentarily as mocks. Here, I may be saying the same as you:
Yes, Smalltalk is great language and it has great tools. This damps some aspects of the problems TDD and Mocks address, but for sure does not remove them totally.
2) Another dynamic language feature is that you can more easily structure tests so the same test can be run against both the mock and the real object when the latter is available. (The approach is the same as in my talk "eXtreme UI Testing" at Smalltalk Solutions 2007, also reachable from the http://www.esug.org/Conferences page.) These features may sometimes make people less thorough in setting up a full mocks framework for their application's tests.
It even seems (to me), TDD is not as widely used as it could and should be (despite the fact it was born in Smalltalk).
I don't think TDD is in the least unpopular or unrespected in Smalltalk. However I'm sure you are right when you say it "is not as widely used as it could and should be", though I'd be surprised if that were more true of Smalltalk than of other languages.
I have been using TDD and Mocks for many years in different projects with Smalltalk and other languages. Sometimes it was hard, sometimes I was even giving it up, but by now I think I have sufficient experience to state that TDD in general and Mock Objects specifically do deserve (at least) more attention by Smalltalkers. ... I was most productive in Smalltalk when I used "classic TDD" and mocks in conjunction.
If your talk uses your experience to illuminate why what we "could and should be" doing was "sometimes ... hard ... even giving it up", but "most productive", that might be very useful to others. Yours faithfully Niall Ross ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Hi Dennis, I completely agree with Niall... I participated in the development of a systems, in VASmalltalk & GemStone, that has 23.000 tests that run in 7 minutes and we hardly needed to use mocks... we mostly needed to have polymorphic objets with the real ones and sometimes we used the same test to do it and sometimes we just used the real ones that were created using resources... I prefer to use real objects instead of mocks or test doubles because when using test doubles (which includes mocks) you are not testing the real thing, so for example, I do not use test doubles for objects that are part of the system I'm writing but only for objects outside the system. My experience of teaching/coaching TDD shows that test doubles are more important due to its difficulty of using, in statically typed languages, which makes sense because the coupling between the "client" object and the "server" object is the variable's type instead of only the messages that are sent. I also believe that TDD is popular in Smalltalk... why do you think it is not? Bye! Hernan. On Fri, May 27, 2011 at 10:16 AM, Niall Ross <nfr@bigwig.net> wrote:
Dear Dennis,
I'd like to explore interest to Mock Object in Smalltalk society. I'm currently working on the topic, preparing a paper and presentation targeting at ESUG 2011.
Sounds interesting.
Steve Freeman (via Joseph Pelrine) wrote:
You should talk to Tim, he wrote a mocks library in about 3 classes (which
is what it should take). He also has some interesting experience from the Kapital project that doesn't have unit tests.
Tim Mackinnon mentions mock objects in his talk 'Expressive Testing and Code for Free' at ESUG 2007 (report reachable from http://www.esug.org/Conferences).
You remark
Apparently, Mocks technique is not popular tool among Smalltalkers.
and Steve, noting that, says
I hadn't realised that the ST world was behind in this respect.
I note that one or two who replied to your earlier post said they had not needed Mocks, or found them brittle, but I don't think the technique is _unpopular_ in Smalltalk. My own take is
1) Smalltalk's power means mocks are not needed as often. Many a time, you can get at what you need directly, or by use method wrappers to make the real objects (or the routes to them) act momentarily as mocks.
Here, I may be saying the same as you:
Yes, Smalltalk is great language and it has great tools.
This damps some aspects of the problems TDD and Mocks address, but for sure does not remove them totally.
2) Another dynamic language feature is that you can more easily structure tests so the same test can be run against both the mock and the real object when the latter is available. (The approach is the same as in my talk "eXtreme UI Testing" at Smalltalk Solutions 2007, also reachable from the http://www.esug.org/Conferences page.)
These features may sometimes make people less thorough in setting up a full mocks framework for their application's tests.
It even seems (to me), TDD is not as widely used as it could and should
be (despite the fact it was born in Smalltalk).
I don't think TDD is in the least unpopular or unrespected in Smalltalk. However I'm sure you are right when you say it "is not as widely used as it could and should be", though I'd be surprised if that were more true of Smalltalk than of other languages.
I have been using TDD and
Mocks for many years in different projects with Smalltalk and other languages. Sometimes it was hard, sometimes I was even giving it up, but by now I think I have sufficient experience to state that TDD in general and Mock Objects specifically do deserve (at least) more attention by Smalltalkers. ... I was most productive in Smalltalk when I used
"classic TDD" and mocks in conjunction.
If your talk uses your experience to illuminate why what we "could and should be" doing was "sometimes ... hard ... even giving it up", but "most productive", that might be very useful to others.
Yours faithfully Niall Ross
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email____________________________________________...
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*
You miss the point of mocks. Mocks are there to allow you to test your code quickly and cheaply against things that may not work in a quick manner. Further, they allow you to isolate yourself from external systems. If you need a database running for your tests to pass, you are not unit testing, but integration testing. You do need to do both, but they serve different purposes. Lastly, mocks document the protocols your objects use to collaborate with each other. They are much more than post-fact assertions. Someone's already mentioned the excellent Growing Object Oriented Systems Guided by Tests (Tim wrote the afterword for it). My two cents? We have at least the beginnings of a framework inside SSpec, a project which dearly needs some love and attention. It's globally writable so contributing to it is easy. In particular, when next I get a chance - hopefully this next month - I'd like to address some of its quirks, split SSpec's DSL from the mocking library, integrate SSpec into TestRunner (or at least make the expectations runnable from TestRunner), and make sure the TextTestRunner still works. What I don't want to see is everyone publishing their own incompatible frameworks or, just as bad, noone doing anything because "oh we don't need mocks". We do need them, and we need a well-implemented feature-complete cross-dialect framework. frank On 27 May 2011 19:41, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
Hi Dennis, I completely agree with Niall... I participated in the development of a systems, in VASmalltalk & GemStone, that has 23.000 tests that run in 7 minutes and we hardly needed to use mocks... we mostly needed to have polymorphic objets with the real ones and sometimes we used the same test to do it and sometimes we just used the real ones that were created using resources... I prefer to use real objects instead of mocks or test doubles because when using test doubles (which includes mocks) you are not testing the real thing, so for example, I do not use test doubles for objects that are part of the system I'm writing but only for objects outside the system. My experience of teaching/coaching TDD shows that test doubles are more important due to its difficulty of using, in statically typed languages, which makes sense because the coupling between the "client" object and the "server" object is the variable's type instead of only the messages that are sent. I also believe that TDD is popular in Smalltalk... why do you think it is not? Bye! Hernan.
On Fri, May 27, 2011 at 10:16 AM, Niall Ross <nfr@bigwig.net> wrote:
Dear Dennis,
I'd like to explore interest to Mock Object in Smalltalk society. I'm currently working on the topic, preparing a paper and presentation targeting at ESUG 2011.
Sounds interesting.
Steve Freeman (via Joseph Pelrine) wrote:
You should talk to Tim, he wrote a mocks library in about 3 classes (which is what it should take). He also has some interesting experience from the Kapital project that doesn't have unit tests.
Tim Mackinnon mentions mock objects in his talk 'Expressive Testing and Code for Free' at ESUG 2007 (report reachable from http://www.esug.org/Conferences).
You remark
Apparently, Mocks technique is not popular tool among Smalltalkers.
and Steve, noting that, says
I hadn't realised that the ST world was behind in this respect.
I note that one or two who replied to your earlier post said they had not needed Mocks, or found them brittle, but I don't think the technique is _unpopular_ in Smalltalk. My own take is
1) Smalltalk's power means mocks are not needed as often. Many a time, you can get at what you need directly, or by use method wrappers to make the real objects (or the routes to them) act momentarily as mocks.
Here, I may be saying the same as you:
Yes, Smalltalk is great language and it has great tools. This damps some aspects of the problems TDD and Mocks address, but for sure does not remove them totally.
2) Another dynamic language feature is that you can more easily structure tests so the same test can be run against both the mock and the real object when the latter is available. (The approach is the same as in my talk "eXtreme UI Testing" at Smalltalk Solutions 2007, also reachable from the http://www.esug.org/Conferences page.)
These features may sometimes make people less thorough in setting up a full mocks framework for their application's tests.
It even seems (to me), TDD is not as widely used as it could and should be (despite the fact it was born in Smalltalk).
I don't think TDD is in the least unpopular or unrespected in Smalltalk. However I'm sure you are right when you say it "is not as widely used as it could and should be", though I'd be surprised if that were more true of Smalltalk than of other languages.
I have been using TDD and Mocks for many years in different projects with Smalltalk and other languages. Sometimes it was hard, sometimes I was even giving it up, but by now I think I have sufficient experience to state that TDD in general and Mock Objects specifically do deserve (at least) more attention by Smalltalkers. ... I was most productive in Smalltalk when I used "classic TDD" and mocks in conjunction.
If your talk uses your experience to illuminate why what we "could and should be" doing was "sometimes ... hard ... even giving it up", but "most productive", that might be very useful to others.
Yours faithfully Niall Ross
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Hi Frank, On Fri, May 27, 2011 at 4:42 PM, Frank Shearar <frank.shearar@gmail.com>wrote:
You miss the point of mocks. Mocks are there to allow you to test your code quickly and cheaply against things that may not work in a quick manner.
well, not really, I mean 23.000 tests in 7 minutes I think is quick enough :-) I'm not saying mocks are not important, but I think sometimes they are overused, that's all.
Further, they allow you to isolate yourself from external systems. If you need a database running for your tests to pass, you are not unit testing, but integration testing. You do need to do both, but they serve different purposes.
I agree, and I think I mentioned that... we use test doubles (not only mocks) for those types of tests.
Lastly, mocks document the protocols your objects use to collaborate with each other. They are much more than post-fact assertions.
I don't understand this... why would I use mocks to document protocolos if I alredy have the real objects with their protocol and the tests documenting them with concrete examples?
Someone's already mentioned the excellent Growing Object Oriented Systems Guided by Tests (Tim wrote the afterword for it).
yeah... but I don't like too much what they proposed is that book :-) (I told that to Tim :-)) but that is another story :-)
My two cents? We have at least the beginnings of a framework inside SSpec, a project which dearly needs some love and attention. It's globally writable so contributing to it is easy.
In particular, when next I get a chance - hopefully this next month - I'd like to address some of its quirks, split SSpec's DSL from the mocking library, integrate SSpec into TestRunner (or at least make the expectations runnable from TestRunner), and make sure the TextTestRunner still works.
What I don't want to see is everyone publishing their own incompatible frameworks or, just as bad, noone doing anything because "oh we don't need mocks". We do need them, and we need a well-implemented feature-complete cross-dialect framework.
hey, I'm not saying this should not be done, just only I don't see mocks as important as some people see them, that's all. I'd like to have a "well-implemented feature-complete cross-dialect framework" mock model of course. Bye! Hernan.
frank
On 27 May 2011 19:41, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
Hi Dennis, I completely agree with Niall... I participated in the development of a systems, in VASmalltalk & GemStone, that has 23.000 tests that run in 7 minutes and we hardly needed to use mocks... we mostly needed to have polymorphic objets with the real ones and sometimes we used the same test to do it and sometimes we just used the real ones that were created using resources... I prefer to use real objects instead of mocks or test doubles because when using test doubles (which includes mocks) you are not testing the real thing, so for example, I do not use test doubles for objects that are part of the system I'm writing but only for objects outside the system. My experience of teaching/coaching TDD shows that test doubles are more important due to its difficulty of using, in statically typed languages, which makes sense because the coupling between the "client" object and the "server" object is the variable's type instead of only the messages that are sent. I also believe that TDD is popular in Smalltalk... why do you think it is not? Bye! Hernan.
On Fri, May 27, 2011 at 10:16 AM, Niall Ross <nfr@bigwig.net> wrote:
Dear Dennis,
I'd like to explore interest to Mock Object in Smalltalk society. I'm currently working on the topic, preparing a paper and presentation targeting at ESUG 2011.
Sounds interesting.
Steve Freeman (via Joseph Pelrine) wrote:
You should talk to Tim, he wrote a mocks library in about 3 classes (which is what it should take). He also has some interesting experience
from
the Kapital project that doesn't have unit tests.
Tim Mackinnon mentions mock objects in his talk 'Expressive Testing and Code for Free' at ESUG 2007 (report reachable from http://www.esug.org/Conferences).
You remark
Apparently, Mocks technique is not popular tool among Smalltalkers.
and Steve, noting that, says
I hadn't realised that the ST world was behind in this respect.
I note that one or two who replied to your earlier post said they had not needed Mocks, or found them brittle, but I don't think the technique is _unpopular_ in Smalltalk. My own take is
1) Smalltalk's power means mocks are not needed as often. Many a time, you can get at what you need directly, or by use method wrappers to make the real objects (or the routes to them) act momentarily as mocks.
Here, I may be saying the same as you:
Yes, Smalltalk is great language and it has great tools. This damps some aspects of the problems TDD and Mocks address, but for sure does not remove them totally.
2) Another dynamic language feature is that you can more easily structure tests so the same test can be run against both the mock and the real object when the latter is available. (The approach is the same as in my talk "eXtreme UI Testing" at Smalltalk Solutions 2007, also reachable from the http://www.esug.org/Conferences page.)
These features may sometimes make people less thorough in setting up a full mocks framework for their application's tests.
It even seems (to me), TDD is not as widely used as it could and should be (despite the fact it was born in Smalltalk).
I don't think TDD is in the least unpopular or unrespected in Smalltalk. However I'm sure you are right when you say it "is not as widely used as it could and should be", though I'd be surprised if that were more true of Smalltalk than of other languages.
I have been using TDD and Mocks for many years in different projects with Smalltalk and other languages. Sometimes it was hard, sometimes I was even giving it up, but by now I think I have sufficient experience to state that TDD in general and Mock Objects specifically do deserve (at least) more attention by Smalltalkers. ... I was most productive in Smalltalk when I used "classic TDD" and mocks in conjunction.
If your talk uses your experience to illuminate why what we "could and should be" doing was "sometimes ... hard ... even giving it up", but "most productive", that might be very useful to others.
Yours faithfully Niall Ross
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*
Lastly, mocks document the protocols your objects use to collaborate
with each other. They are much more than post-fact assertions.
I don't understand this... why would I use mocks to document protocolos if I alredy have the real objects with their protocol and the tests documenting them with concrete examples?
The tests will document the use of the methods, but mocks allow you to ensure the separation of public and private protocols by only offering the public protocol on your mocks. If your code breaches this separation, your tests will fail with MNUs. Obviously, it only works if the mock object is implemented respecting that separation ;-) Cheers, Yann On Fri, May 27, 2011 at 10:05 PM, Hernan Wilkinson < hernan.wilkinson@10pines.com> wrote:
Hi Frank,
On Fri, May 27, 2011 at 4:42 PM, Frank Shearar <frank.shearar@gmail.com>wrote:
You miss the point of mocks. Mocks are there to allow you to test your code quickly and cheaply against things that may not work in a quick manner.
well, not really, I mean 23.000 tests in 7 minutes I think is quick enough :-) I'm not saying mocks are not important, but I think sometimes they are overused, that's all.
Further, they allow you to isolate yourself from external systems. If you need a database running for your tests to pass, you are not unit testing, but integration testing. You do need to do both, but they serve different purposes.
I agree, and I think I mentioned that... we use test doubles (not only mocks) for those types of tests.
Lastly, mocks document the protocols your objects use to collaborate with each other. They are much more than post-fact assertions.
I don't understand this... why would I use mocks to document protocolos if I alredy have the real objects with their protocol and the tests documenting them with concrete examples?
Someone's already mentioned the excellent Growing Object Oriented Systems Guided by Tests (Tim wrote the afterword for it).
yeah... but I don't like too much what they proposed is that book :-) (I told that to Tim :-)) but that is another story :-)
My two cents? We have at least the beginnings of a framework inside SSpec, a project which dearly needs some love and attention. It's globally writable so contributing to it is easy.
In particular, when next I get a chance - hopefully this next month - I'd like to address some of its quirks, split SSpec's DSL from the mocking library, integrate SSpec into TestRunner (or at least make the expectations runnable from TestRunner), and make sure the TextTestRunner still works.
What I don't want to see is everyone publishing their own incompatible frameworks or, just as bad, noone doing anything because "oh we don't need mocks". We do need them, and we need a well-implemented feature-complete cross-dialect framework.
hey, I'm not saying this should not be done, just only I don't see mocks as important as some people see them, that's all. I'd like to have a "well-implemented feature-complete cross-dialect framework" mock model of course.
Bye! Hernan.
frank
On 27 May 2011 19:41, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
Hi Dennis, I completely agree with Niall... I participated in the development of a systems, in VASmalltalk & GemStone, that has 23.000 tests that run in 7 minutes and we hardly needed to use mocks... we mostly needed to have polymorphic objets with the real ones and sometimes we used the same test to do it and sometimes we just used the real ones that were created using resources... I prefer to use real objects instead of mocks or test doubles because when using test doubles (which includes mocks) you are not testing the real thing, so for example, I do not use test doubles for objects that are part of the system I'm writing but only for objects outside the system. My experience of teaching/coaching TDD shows that test doubles are more important due to its difficulty of using, in statically typed languages, which makes sense because the coupling between the "client" object and the "server" object is the variable's type instead of only the messages that are sent. I also believe that TDD is popular in Smalltalk... why do you think it is not? Bye! Hernan.
On Fri, May 27, 2011 at 10:16 AM, Niall Ross <nfr@bigwig.net> wrote:
Dear Dennis,
I'd like to explore interest to Mock Object in Smalltalk society. I'm currently working on the topic, preparing a paper and presentation targeting at ESUG 2011.
Sounds interesting.
Steve Freeman (via Joseph Pelrine) wrote:
You should talk to Tim, he wrote a mocks library in about 3 classes (which is what it should take). He also has some interesting
experience from
the Kapital project that doesn't have unit tests.
Tim Mackinnon mentions mock objects in his talk 'Expressive Testing and Code for Free' at ESUG 2007 (report reachable from http://www.esug.org/Conferences).
You remark
Apparently, Mocks technique is not popular tool among Smalltalkers.
and Steve, noting that, says
I hadn't realised that the ST world was behind in this respect.
I note that one or two who replied to your earlier post said they had not needed Mocks, or found them brittle, but I don't think the technique is _unpopular_ in Smalltalk. My own take is
1) Smalltalk's power means mocks are not needed as often. Many a time, you can get at what you need directly, or by use method wrappers to make the real objects (or the routes to them) act momentarily as mocks.
Here, I may be saying the same as you:
Yes, Smalltalk is great language and it has great tools. This damps some aspects of the problems TDD and Mocks address, but for sure does not remove them totally.
2) Another dynamic language feature is that you can more easily structure tests so the same test can be run against both the mock and the real object when the latter is available. (The approach is the same as in my talk "eXtreme UI Testing" at Smalltalk Solutions 2007, also reachable from the http://www.esug.org/Conferences page.)
These features may sometimes make people less thorough in setting up a full mocks framework for their application's tests.
It even seems (to me), TDD is not as widely used as it could and should be (despite the fact it was born in Smalltalk).
I don't think TDD is in the least unpopular or unrespected in Smalltalk. However I'm sure you are right when you say it "is not as widely used as it could and should be", though I'd be surprised if that were more true of Smalltalk than of other languages.
I have been using TDD and Mocks for many years in different projects with Smalltalk and other languages. Sometimes it was hard, sometimes I was even giving it up, but by now I think I have sufficient experience to state that TDD in general and Mock Objects specifically do deserve (at least) more attention by Smalltalkers. ... I was most productive in Smalltalk when I used "classic TDD" and mocks in conjunction.
If your talk uses your experience to illuminate why what we "could and should be" doing was "sometimes ... hard ... even giving it up", but "most productive", that might be very useful to others.
Yours faithfully Niall Ross
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
On 27 May 2011 21:25, Yann Monclair <yann@monclair.fr> wrote:
Lastly, mocks document the protocols your objects use to collaborate with each other. They are much more than post-fact assertions.
I don't understand this... why would I use mocks to document protocolos if I alredy have the real objects with their protocol and the tests documenting them with concrete examples?
The tests will document the use of the methods, but mocks allow you to ensure the separation of public and private protocols by only offering the public protocol on your mocks. If your code breaches this separation, your tests will fail with MNUs. Obviously, it only works if the mock object is implemented respecting that separation ;-)
Indeed, I was just saying to someone off-list that I forgot one of the more important reasons for using mocks. Firstly that separation of public and private protocols and, secondly, still being able to test that our object behaves sanely in response to a bad peer. Using mocks allows the _test_ to control the interaction - the interaction's laid out in the test, in other words - and also allows the test to inject errors: "fail when you call this method the _second_ time", for instance. frank
Cheers, Yann On Fri, May 27, 2011 at 10:05 PM, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
Hi Frank,
On Fri, May 27, 2011 at 4:42 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
You miss the point of mocks. Mocks are there to allow you to test your code quickly and cheaply against things that may not work in a quick manner.
well, not really, I mean 23.000 tests in 7 minutes I think is quick enough :-) I'm not saying mocks are not important, but I think sometimes they are overused, that's all.
Further, they allow you to isolate yourself from external systems. If you need a database running for your tests to pass, you are not unit testing, but integration testing. You do need to do both, but they serve different purposes.
I agree, and I think I mentioned that... we use test doubles (not only mocks) for those types of tests.
Lastly, mocks document the protocols your objects use to collaborate with each other. They are much more than post-fact assertions.
I don't understand this... why would I use mocks to document protocolos if I alredy have the real objects with their protocol and the tests documenting them with concrete examples?
Someone's already mentioned the excellent Growing Object Oriented Systems Guided by Tests (Tim wrote the afterword for it).
yeah... but I don't like too much what they proposed is that book :-) (I told that to Tim :-)) but that is another story :-)
My two cents? We have at least the beginnings of a framework inside SSpec, a project which dearly needs some love and attention. It's globally writable so contributing to it is easy.
In particular, when next I get a chance - hopefully this next month - I'd like to address some of its quirks, split SSpec's DSL from the mocking library, integrate SSpec into TestRunner (or at least make the expectations runnable from TestRunner), and make sure the TextTestRunner still works.
What I don't want to see is everyone publishing their own incompatible frameworks or, just as bad, noone doing anything because "oh we don't need mocks". We do need them, and we need a well-implemented feature-complete cross-dialect framework.
hey, I'm not saying this should not be done, just only I don't see mocks as important as some people see them, that's all. I'd like to have a "well-implemented feature-complete cross-dialect framework" mock model of course. Bye! Hernan.
frank
On 27 May 2011 19:41, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
Hi Dennis, I completely agree with Niall... I participated in the development of a systems, in VASmalltalk & GemStone, that has 23.000 tests that run in 7 minutes and we hardly needed to use mocks... we mostly needed to have polymorphic objets with the real ones and sometimes we used the same test to do it and sometimes we just used the real ones that were created using resources... I prefer to use real objects instead of mocks or test doubles because when using test doubles (which includes mocks) you are not testing the real thing, so for example, I do not use test doubles for objects that are part of the system I'm writing but only for objects outside the system. My experience of teaching/coaching TDD shows that test doubles are more important due to its difficulty of using, in statically typed languages, which makes sense because the coupling between the "client" object and the "server" object is the variable's type instead of only the messages that are sent. I also believe that TDD is popular in Smalltalk... why do you think it is not? Bye! Hernan.
On Fri, May 27, 2011 at 10:16 AM, Niall Ross <nfr@bigwig.net> wrote:
Dear Dennis,
I'd like to explore interest to Mock Object in Smalltalk society. I'm currently working on the topic, preparing a paper and presentation targeting at ESUG 2011.
Sounds interesting.
Steve Freeman (via Joseph Pelrine) wrote:
You should talk to Tim, he wrote a mocks library in about 3 classes (which is what it should take). He also has some interesting experience from the Kapital project that doesn't have unit tests.
Tim Mackinnon mentions mock objects in his talk 'Expressive Testing and Code for Free' at ESUG 2007 (report reachable from http://www.esug.org/Conferences).
You remark
Apparently, Mocks technique is not popular tool among Smalltalkers.
and Steve, noting that, says
I hadn't realised that the ST world was behind in this respect.
I note that one or two who replied to your earlier post said they had not needed Mocks, or found them brittle, but I don't think the technique is _unpopular_ in Smalltalk. My own take is
1) Smalltalk's power means mocks are not needed as often. Many a time, you can get at what you need directly, or by use method wrappers to make the real objects (or the routes to them) act momentarily as mocks.
Here, I may be saying the same as you:
> Yes, Smalltalk is great language and it has great tools. > This damps some aspects of the problems TDD and Mocks address, but > for > sure does not remove them totally.
2) Another dynamic language feature is that you can more easily structure tests so the same test can be run against both the mock and the real object when the latter is available. (The approach is the same as in my talk "eXtreme UI Testing" at Smalltalk Solutions 2007, also reachable from the http://www.esug.org/Conferences page.)
These features may sometimes make people less thorough in setting up a full mocks framework for their application's tests.
> It even seems (to me), TDD is not as widely used as it could and > should > be (despite the fact it was born in Smalltalk).
I don't think TDD is in the least unpopular or unrespected in Smalltalk. However I'm sure you are right when you say it "is not as widely used as it could and should be", though I'd be surprised if that were more true of Smalltalk than of other languages.
> I have been using TDD and > Mocks for many years in different projects with Smalltalk and other > languages. Sometimes it was hard, sometimes I was even giving it up, > but > by now I think I have sufficient experience to state that TDD in > general > and Mock Objects specifically do deserve (at least) more attention > by > Smalltalkers. ... I was most productive in Smalltalk when I used > "classic TDD" and mocks in conjunction.
If your talk uses your experience to illuminate why what we "could and should be" doing was "sometimes ... hard ... even giving it up", but "most productive", that might be very useful to others.
Yours faithfully Niall Ross
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
This has been an interesting thread - and it definitely seems that there is enough interested to warrant a further talk on the subject. I encourage Frank to pursue his idea to submit a talk (sadly I can't attend ESUG this year - which I am disappointed about. However maybe Frank and I can confer offline, and I can share some ideas) As Neil pointed out (and more for background info) - I did present the ideas behind Mocks (and the library SMock, that was written for Dolphin) - back in 2007. I also did an update at Smalltalks 2009 and used the following screencast - http://www.planningcards.com/Thoughts/SMock%20and%20TDD%20in%20action.htm. I have to confess that I keep promising to fully port SMock to Pharo/Squeak - and have done most of the work but I got a bit stuck with Monticello and how to properly do extension methods as well as getting diverted onto other things. It also felt that people weren't very interested in the technique so I was writing something more for myself and for researching how it would impact my Smalltalk coding experience. (By the way there is now much more documentation on how to use Monticello, and Pharo is so much better, and with our renewed energy in the UKSmalltalk meetings I'm more inspired to seek some help to get something checked in). It sounds like Frank also has another interesting library that we should compare (and since then I have augmented another internal Mock library on a JPMorgan project which approaches things in a slightly different manner). While SteveF mentioned that we can implement testing strategies in quite a small amount of Smalltalk code - the bulk of code actually comes in making test failures communicate clearly and explicitly as well as giving you a nice level of expression that keeps tests readable (I think these latter points are very important for long lasting, useful tests). Having said all of this - many of these conversations do indicated a slight misunderstanding of Mocks and where they came from. To fill in a bit of background: When I helped invent the approach it was very much driven from wanting to do TDD - and although it was originally written in Java it was inspired from my experience in Smalltalk. I am particularly fond of CRC cards - and the approach of "role-playing" objects and interactions (yet another Smalltalk invention). In our experiments with TDD in 1999, I found that our Java testing seemed "dumbed down - and we were often tempted to add "getter" methods to just test something. It seemed a far cry from Smalltalk and CRC - until we focused back on how to express that role play in our test code by not adding getter methods. Thus if you did take the time to CRC - and looked at who you collaborated with - then expressing that in a test became more interesting. "I am supposed to collaborate with the PayrollCalculator - and if its the end of the month then I should ask it to #calculatePensionFor: employee on: date for every employee in my dataset. If I get the wrong date, or don't ask about every employee then I should fail the test." We found that if you could focus on encoding the CRC session in your tests, that you got better tests and better code, as well as better test failures. In Java it felt like you got code that was more Smalltalk like. So I guess I would comment that for us, Mocks were different because we wanted to focus testing on asserting relationships and interactions and less on data values. I read all the literature at the time (there is a massive book on Testing on my bookshelf from that time) - and nothing else seemed to have this same focus (stubs felt more data related). As we played with this more and more, we refactored out useful techniques to ease the assertion of relationships, and someone coined the term "Needs driven development". That is, the act of thinking in this way made you want to have relationships that you could assert against. For me - these were the "interesting tests" that we had been writing back in Connextra that felt better than the others. I think this also came out of our experiences of using TDD - and the observation that when you write tests for objects that you consider low hanging fruit (because you know you need them, and they seem easy to test) - invariably you make the wrong decision and test that something threw an exception instead of returning a boolean (or better still in Smalltalk, has an ifAbsent: style construct). Of course you only find out about this when you go to plug your well tested object into the place where you need it and discover that if you had just returned true/false then it would be much easier to use. So you go back, rejig the tests and you get a bit further until you discover another slightly wonky decision. After doing this a few times I made a point of saying to my team mates, lets always start with the top most object and write tests that help us learn what these smaller pieces (which we know we need) should actually do. This resonated well with CRC and really brought everything together for us. This is how MockObjects were born (and I asked Steve and Nat if they would like a chapter in their GOOS book about this history - and they happily included it as an afterward at the back). So coming back to Smalltalk - I still would argue that this CRC technique is very much alive, and I personally still find that "Needs Driven Development" is a useful technique. However it does mean that you get into a chicken and egg situation. If you start testing with a high level object - how do you test or get something working when you are referring to things that don't yet exist? For me, thats where Mocks step in - they are intended to be light weight proxies for things that don't yet exist. You do a CRC session, pick out the highest level object you can - code it (with tests) and mock out the relationships that you recorded on your CRC cards. As you are coding it, you will probably change your mind (writing real code has a way of doing that) - and you modify your lightweight relationship assertions (mocks). This also works best and is easier if you delegate responsibility and avoid returning complicated things (its easier to Mock and happily conforms to the law of Demeter). When you are happy enough with your top level object - you can then pick on one of those other relationships, and your tests should now show you the "Protocol" that this new object should have. So you create it - and repeat the process. The interesting twist that the screencast I linked to demonstrates - is that in Smalltalk (and indeed in Ruby or Python) we can create MockObjects that don't have any code, however you can use all those assertions to actually generate an object ready for you to test it. I think this is an interesting idea that needs more research (I feel that the right assertions could generate interesting code). As a final observation - when people talk about TestDoubles and MethodWrappers, I think they are missing the point of mocks as I intended them - as you can't double or wrap something that isn't yet written? So I would say that these techniques are perhaps better suited to code that is already in existence. Of course once you have done TDD with Mocks, and written your code you are then in a place where you can decide what to do? For me - I have kept the mocks in place - however I think in Smalltalk there is possibly a useful "Lint" check that makes sure your mock stays in sync with the underlying code (I haven't written any Slime style rules - but I think it would be interesting). There is also a useful hybrid functionality where you only mock certain methods and pass control to a real object underneath - or "method wrap" and decorate assertions you want on existing methods and pass down to the functionality underneath. I would argue that these are possibly more "maintenance" or "integration" style endeavours - and it would be a shame to not use the purer "Needs driven development" style when you can. Anyway - I hope this is a useful background and might inspire more work in the area. Tim
I read your message after I've posted my attempt to explain ideas behind mocks. Now I see there were no need for that. :) Very good and clear, just great explanation! 2011/5/29 Tim Mackinnon <macta@pobox.com>
This has been an interesting thread - and it definitely seems that there is enough interested to warrant a further talk on the subject. I encourage Frank to pursue his idea to submit a talk (sadly I can't attend ESUG this year - which I am disappointed about. However maybe Frank and I can confer offline, and I can share some ideas)
As Neil pointed out (and more for background info) - I did present the ideas behind Mocks (and the library SMock, that was written for Dolphin) - back in 2007. I also did an update at Smalltalks 2009 and used the following screencast - http://www.planningcards.com/Thoughts/SMock%20and%20TDD%20in%20action.htm.
I have to confess that I keep promising to fully port SMock to Pharo/Squeak - and have done most of the work but I got a bit stuck with Monticello and how to properly do extension methods as well as getting diverted onto other things. It also felt that people weren't very interested in the technique so I was writing something more for myself and for researching how it would impact my Smalltalk coding experience. (By the way there is now much more documentation on how to use Monticello, and Pharo is so much better, and with our renewed energy in the UKSmalltalk meetings I'm more inspired to seek some help to get something checked in). It sounds like Frank also has another interesting library that we should compare (and since then I have augmented another internal Mock library on a JPMorgan project which approaches things in a slightly different manner). While SteveF mentioned that we can implement testing strategies in quite a small amount of Smalltalk code - the bulk of code actually comes in making test failures communicate clearly and explicitly as well as giving you a nice level of expression that keeps tests readable (I think these latter points are very important for long lasting, useful tests).
Having said all of this - many of these conversations do indicated a slight misunderstanding of Mocks and where they came from. To fill in a bit of background:
When I helped invent the approach it was very much driven from wanting to do TDD - and although it was originally written in Java it was inspired from my experience in Smalltalk. I am particularly fond of CRC cards - and the approach of "role-playing" objects and interactions (yet another Smalltalk invention). In our experiments with TDD in 1999, I found that our Java testing seemed "dumbed down - and we were often tempted to add "getter" methods to just test something. It seemed a far cry from Smalltalk and CRC - until we focused back on how to express that role play in our test code by not adding getter methods. Thus if you did take the time to CRC - and looked at who you collaborated with - then expressing that in a test became more interesting. "I am supposed to collaborate with the PayrollCalculator - and if its the end of the month then I should ask it to #calculatePensionFor: employee on: date for every employee in my dataset. If I get the wrong date, or don't ask about every employee then I should fail the test." We found that if you could focus on encoding the CRC session in your tests, that you got better tests and better code, as well as better test failures. In Java it felt like you got code that was more Smalltalk like.
So I guess I would comment that for us, Mocks were different because we wanted to focus testing on asserting relationships and interactions and less on data values. I read all the literature at the time (there is a massive book on Testing on my bookshelf from that time) - and nothing else seemed to have this same focus (stubs felt more data related). As we played with this more and more, we refactored out useful techniques to ease the assertion of relationships, and someone coined the term "Needs driven development". That is, the act of thinking in this way made you want to have relationships that you could assert against. For me - these were the "interesting tests" that we had been writing back in Connextra that felt better than the others.
I think this also came out of our experiences of using TDD - and the observation that when you write tests for objects that you consider low hanging fruit (because you know you need them, and they seem easy to test) - invariably you make the wrong decision and test that something threw an exception instead of returning a boolean (or better still in Smalltalk, has an ifAbsent: style construct). Of course you only find out about this when you go to plug your well tested object into the place where you need it and discover that if you had just returned true/false then it would be much easier to use. So you go back, rejig the tests and you get a bit further until you discover another slightly wonky decision. After doing this a few times I made a point of saying to my team mates, lets always start with the top most object and write tests that help us learn what these smaller pieces (which we know we need) should actually do. This resonated well with CRC and really brought everything together for us. This is how MockObjects were born (and I asked Steve and Nat if they would like a chapter in their GOOS book about this history - and they happily included it as an afterward at the back).
So coming back to Smalltalk - I still would argue that this CRC technique is very much alive, and I personally still find that "Needs Driven Development" is a useful technique. However it does mean that you get into a chicken and egg situation. If you start testing with a high level object - how do you test or get something working when you are referring to things that don't yet exist? For me, thats where Mocks step in - they are intended to be light weight proxies for things that don't yet exist. You do a CRC session, pick out the highest level object you can - code it (with tests) and mock out the relationships that you recorded on your CRC cards. As you are coding it, you will probably change your mind (writing real code has a way of doing that) - and you modify your lightweight relationship assertions (mocks). This also works best and is easier if you delegate responsibility and avoid returning complicated things (its easier to Mock and happily conforms to the law of Demeter).
When you are happy enough with your top level object - you can then pick on one of those other relationships, and your tests should now show you the "Protocol" that this new object should have. So you create it - and repeat the process. The interesting twist that the screencast I linked to demonstrates - is that in Smalltalk (and indeed in Ruby or Python) we can create MockObjects that don't have any code, however you can use all those assertions to actually generate an object ready for you to test it. I think this is an interesting idea that needs more research (I feel that the right assertions could generate interesting code).
As a final observation - when people talk about TestDoubles and MethodWrappers, I think they are missing the point of mocks as I intended them - as you can't double or wrap something that isn't yet written? So I would say that these techniques are perhaps better suited to code that is already in existence. Of course once you have done TDD with Mocks, and written your code you are then in a place where you can decide what to do? For me - I have kept the mocks in place - however I think in Smalltalk there is possibly a useful "Lint" check that makes sure your mock stays in sync with the underlying code (I haven't written any Slime style rules - but I think it would be interesting). There is also a useful hybrid functionality where you only mock certain methods and pass control to a real object underneath - or "method wrap" and decorate assertions you want on existing methods and pass down to the functionality underneath. I would argue that these are possibly more "maintenance" or "integration" style endeavours - and it would be a shame to not use the purer "Needs driven development" style when you can.
Anyway - I hope this is a useful background and might inspire more work in the area.
Tim
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- Dennis Schetinin
tim send the code so that we can package it well. Stef On May 29, 2011, at 2:31 PM, Tim Mackinnon wrote:
This has been an interesting thread - and it definitely seems that there is enough interested to warrant a further talk on the subject. I encourage Frank to pursue his idea to submit a talk (sadly I can't attend ESUG this year - which I am disappointed about. However maybe Frank and I can confer offline, and I can share some ideas)
As Neil pointed out (and more for background info) - I did present the ideas behind Mocks (and the library SMock, that was written for Dolphin) - back in 2007. I also did an update at Smalltalks 2009 and used the following screencast - http://www.planningcards.com/Thoughts/SMock%20and%20TDD%20in%20action.htm.
I have to confess that I keep promising to fully port SMock to Pharo/Squeak - and have done most of the work but I got a bit stuck with Monticello and how to properly do extension methods as well as getting diverted onto other things. It also felt that people weren't very interested in the technique so I was writing something more for myself and for researching how it would impact my Smalltalk coding experience. (By the way there is now much more documentation on how to use Monticello, and Pharo is so much better, and with our renewed energy in the UKSmalltalk meetings I'm more inspired to seek some help to get something checked in). It sounds like Frank also has another interesting library that we should compare (and since then I have augmented another internal Mock library on a JPMorgan project which approaches things in a slightly different manner). While SteveF mentioned that we can implement testing strategies in quite a small amount of Smalltalk code - the bulk of code actually comes in making test failures communicate clearly and explicitly as well as giving you a nice level of expression that keeps tests readable (I think these latter points are very important for long lasting, useful tests).
Having said all of this - many of these conversations do indicated a slight misunderstanding of Mocks and where they came from. To fill in a bit of background:
When I helped invent the approach it was very much driven from wanting to do TDD - and although it was originally written in Java it was inspired from my experience in Smalltalk. I am particularly fond of CRC cards - and the approach of "role-playing" objects and interactions (yet another Smalltalk invention). In our experiments with TDD in 1999, I found that our Java testing seemed "dumbed down - and we were often tempted to add "getter" methods to just test something. It seemed a far cry from Smalltalk and CRC - until we focused back on how to express that role play in our test code by not adding getter methods. Thus if you did take the time to CRC - and looked at who you collaborated with - then expressing that in a test became more interesting. "I am supposed to collaborate with the PayrollCalculator - and if its the end of the month then I should ask it to #calculatePensionFor: employee on: date for every employee in my dataset. If I get the wrong date, or don't ask about every employee then I should fail the test." We found that if you could focus on encoding the CRC session in your tests, that you got better tests and better code, as well as better test failures. In Java it felt like you got code that was more Smalltalk like.
So I guess I would comment that for us, Mocks were different because we wanted to focus testing on asserting relationships and interactions and less on data values. I read all the literature at the time (there is a massive book on Testing on my bookshelf from that time) - and nothing else seemed to have this same focus (stubs felt more data related). As we played with this more and more, we refactored out useful techniques to ease the assertion of relationships, and someone coined the term "Needs driven development". That is, the act of thinking in this way made you want to have relationships that you could assert against. For me - these were the "interesting tests" that we had been writing back in Connextra that felt better than the others.
I think this also came out of our experiences of using TDD - and the observation that when you write tests for objects that you consider low hanging fruit (because you know you need them, and they seem easy to test) - invariably you make the wrong decision and test that something threw an exception instead of returning a boolean (or better still in Smalltalk, has an ifAbsent: style construct). Of course you only find out about this when you go to plug your well tested object into the place where you need it and discover that if you had just returned true/false then it would be much easier to use. So you go back, rejig the tests and you get a bit further until you discover another slightly wonky decision. After doing this a few times I made a point of saying to my team mates, lets always start with the top most object and write tests that help us learn what these smaller pieces (which we know we need) should actually do. This resonated well with CRC and really brought everything together for us. This is how MockObjects were born (and I asked Steve and Nat if they would like a chapter in their GOOS book about this history - and they happily included it as an afterward at the back).
So coming back to Smalltalk - I still would argue that this CRC technique is very much alive, and I personally still find that "Needs Driven Development" is a useful technique. However it does mean that you get into a chicken and egg situation. If you start testing with a high level object - how do you test or get something working when you are referring to things that don't yet exist? For me, thats where Mocks step in - they are intended to be light weight proxies for things that don't yet exist. You do a CRC session, pick out the highest level object you can - code it (with tests) and mock out the relationships that you recorded on your CRC cards. As you are coding it, you will probably change your mind (writing real code has a way of doing that) - and you modify your lightweight relationship assertions (mocks). This also works best and is easier if you delegate responsibility and avoid returning complicated things (its easier to Mock and happily conforms to the law of Demeter).
When you are happy enough with your top level object - you can then pick on one of those other relationships, and your tests should now show you the "Protocol" that this new object should have. So you create it - and repeat the process. The interesting twist that the screencast I linked to demonstrates - is that in Smalltalk (and indeed in Ruby or Python) we can create MockObjects that don't have any code, however you can use all those assertions to actually generate an object ready for you to test it. I think this is an interesting idea that needs more research (I feel that the right assertions could generate interesting code).
As a final observation - when people talk about TestDoubles and MethodWrappers, I think they are missing the point of mocks as I intended them - as you can't double or wrap something that isn't yet written? So I would say that these techniques are perhaps better suited to code that is already in existence. Of course once you have done TDD with Mocks, and written your code you are then in a place where you can decide what to do? For me - I have kept the mocks in place - however I think in Smalltalk there is possibly a useful "Lint" check that makes sure your mock stays in sync with the underlying code (I haven't written any Slime style rules - but I think it would be interesting). There is also a useful hybrid functionality where you only mock certain methods and pass control to a real object underneath - or "method wrap" and decorate assertions you want on existing methods and pass down to the functionality underneath. I would argue that these are possibly more "maintenance" or "integration" style endeavours - and it would be a shame to not use the purer "Needs driven development" style when you can.
Anyway - I hope this is a useful background and might inspire more work in the area.
Tim
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
On 2 juin 2011, at 21:53, stephane ducasse wrote:
tim send the code so that we can package it well.
Yep I can do that, especially since I'm learning this kind of stuff these days.
Stef
On May 29, 2011, at 2:31 PM, Tim Mackinnon wrote:
This has been an interesting thread - and it definitely seems that there is enough interested to warrant a further talk on the subject. I encourage Frank to pursue his idea to submit a talk (sadly I can't attend ESUG this year - which I am disappointed about. However maybe Frank and I can confer offline, and I can share some ideas)
As Neil pointed out (and more for background info) - I did present the ideas behind Mocks (and the library SMock, that was written for Dolphin) - back in 2007. I also did an update at Smalltalks 2009 and used the following screencast - http://www.planningcards.com/Thoughts/SMock%20and%20TDD%20in%20action.htm.
I have to confess that I keep promising to fully port SMock to Pharo/Squeak - and have done most of the work but I got a bit stuck with Monticello and how to properly do extension methods as well as getting diverted onto other things. It also felt that people weren't very interested in the technique so I was writing something more for myself and for researching how it would impact my Smalltalk coding experience. (By the way there is now much more documentation on how to use Monticello, and Pharo is so much better, and with our renewed energy in the UKSmalltalk meetings I'm more inspired to seek some help to get something checked in). It sounds like Frank also has another interesting library that we should compare (and since then I have augmented another internal Mock library on a JPMorgan project which approaches things in a slightly different manner). While SteveF mentioned that we can implement testing strategies in quite a small amount of Smalltalk code - the bulk of code actually comes in making test failures communicate clearly and explicitly as well as giving you a nice level of expression that keeps tests readable (I think these latter points are very important for long lasting, useful tests).
Having said all of this - many of these conversations do indicated a slight misunderstanding of Mocks and where they came from. To fill in a bit of background:
When I helped invent the approach it was very much driven from wanting to do TDD - and although it was originally written in Java it was inspired from my experience in Smalltalk. I am particularly fond of CRC cards - and the approach of "role-playing" objects and interactions (yet another Smalltalk invention). In our experiments with TDD in 1999, I found that our Java testing seemed "dumbed down - and we were often tempted to add "getter" methods to just test something. It seemed a far cry from Smalltalk and CRC - until we focused back on how to express that role play in our test code by not adding getter methods. Thus if you did take the time to CRC - and looked at who you collaborated with - then expressing that in a test became more interesting. "I am supposed to collaborate with the PayrollCalculator - and if its the end of the month then I should ask it to #calculatePensionFor: employee on: date for every employee in my dataset. If I get the wrong date, or don't ask about every employee then I should fail the test." We found that if you could focus on encoding the CRC session in your tests, that you got better tests and better code, as well as better test failures. In Java it felt like you got code that was more Smalltalk like.
So I guess I would comment that for us, Mocks were different because we wanted to focus testing on asserting relationships and interactions and less on data values. I read all the literature at the time (there is a massive book on Testing on my bookshelf from that time) - and nothing else seemed to have this same focus (stubs felt more data related). As we played with this more and more, we refactored out useful techniques to ease the assertion of relationships, and someone coined the term "Needs driven development". That is, the act of thinking in this way made you want to have relationships that you could assert against. For me - these were the "interesting tests" that we had been writing back in Connextra that felt better than the others.
I think this also came out of our experiences of using TDD - and the observation that when you write tests for objects that you consider low hanging fruit (because you know you need them, and they seem easy to test) - invariably you make the wrong decision and test that something threw an exception instead of returning a boolean (or better still in Smalltalk, has an ifAbsent: style construct). Of course you only find out about this when you go to plug your well tested object into the place where you need it and discover that if you had just returned true/false then it would be much easier to use. So you go back, rejig the tests and you get a bit further until you discover another slightly wonky decision. After doing this a few times I made a point of saying to my team mates, lets always start with the top most object and write tests that help us learn what these smaller pieces (which we know we need) should actually do. This resonated well with CRC and really brought everything together for us. This is how MockObjects were born (and I asked Steve and Nat if they would like a chapter in their GOOS book about this history - and they happily included it as an afterward at the back).
So coming back to Smalltalk - I still would argue that this CRC technique is very much alive, and I personally still find that "Needs Driven Development" is a useful technique. However it does mean that you get into a chicken and egg situation. If you start testing with a high level object - how do you test or get something working when you are referring to things that don't yet exist? For me, thats where Mocks step in - they are intended to be light weight proxies for things that don't yet exist. You do a CRC session, pick out the highest level object you can - code it (with tests) and mock out the relationships that you recorded on your CRC cards. As you are coding it, you will probably change your mind (writing real code has a way of doing that) - and you modify your lightweight relationship assertions (mocks). This also works best and is easier if you delegate responsibility and avoid returning complicated things (its easier to Mock and happily conforms to the law of Demeter).
When you are happy enough with your top level object - you can then pick on one of those other relationships, and your tests should now show you the "Protocol" that this new object should have. So you create it - and repeat the process. The interesting twist that the screencast I linked to demonstrates - is that in Smalltalk (and indeed in Ruby or Python) we can create MockObjects that don't have any code, however you can use all those assertions to actually generate an object ready for you to test it. I think this is an interesting idea that needs more research (I feel that the right assertions could generate interesting code).
As a final observation - when people talk about TestDoubles and MethodWrappers, I think they are missing the point of mocks as I intended them - as you can't double or wrap something that isn't yet written? So I would say that these techniques are perhaps better suited to code that is already in existence. Of course once you have done TDD with Mocks, and written your code you are then in a place where you can decide what to do? For me - I have kept the mocks in place - however I think in Smalltalk there is possibly a useful "Lint" check that makes sure your mock stays in sync with the underlying code (I haven't written any Slime style rules - but I think it would be interesting). There is also a useful hybrid functionality where you only mock certain methods and pass control to a real object underneath - or "method wrap" and decorate assertions you want on existing methods and pass down to the functionality underneath. I would argue that these are possibly more "maintenance" or "integration" style endeavours - and it would be a shame to not use the purer "Needs driven development" style when you can.
Anyway - I hope this is a useful background and might inspire more work in the area.
Tim
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- Simon Denier
what are test doubles? OK guys we will have a really cool discussion at ESUG :)
Test doubles are objects that simulate being other objects... The name comes from the movies were the double replaces the real actor... I really dont like the name, i found it confusing, that is why i prefer to use simulation objects... Anyway, they include fake pbjects, mock objects, dummy objects and bla and bla and bla :-) in the end the only impotant thing is for them to be polimorphic with the object they are replacing implementing a specific behavior for the test they are being used On Saturday, May 28, 2011, stephane ducasse <stephane.ducasse@gmail.com> wrote:
what are test doubles?
OK guys we will have a really cool discussion at ESUG :)
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*
participants (9)
-
Dennis Schetinin -
Frank Shearar -
Hernan Wilkinson -
Joseph Pelrine -
Niall Ross -
Simon Denier -
stephane ducasse -
Tim Mackinnon -
Yann Monclair