May 2011 - Esug-list - lists.esug.org

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer

by Yoshiki Ohshima

At Thu, 26 May 2011 16:45:38 -0300, Martin Dias wrote: > > > On Thu, May 26, 2011 at 4:41 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > On Thu, May 26, 2011 at 9:29 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > > BTW, the page (http://rmod.lille.inria.fr/web/pier/software/Fuel) > says: > > Gofer new > squeaksource: 'Fuel'; > package: 'ConfigurationOfFuel'; > load. > ((Smalltalk at: #ConfigurationOfFuel) project =latestVersion) load: #(Core Tests Benchmarks). > > it does not appear to be a valid expression. What is the right > expression? > > the = > > Hi! > Sorry, now it is fixed. Thanks! I tried it a bit and I'm officially impressed with its performancce ^^; I had a simple serializer/materializer that only handles class definitions and compiled methods (and initialization of classes). But Fuel seems faster than that for a factor of two or so for reading methods. (Mine was more on simplicity so it has only a few methods and does some slow way to read sized-strings, as well as generous 4 byte padding. It does make difference when it comes to performance.) -- Yoshiki

May 27, 2011

Re: [Esug-list] Fwd: Re: Proposal for Mock Objects at ESUG 2011

by Frank Shearar

On 27 May 2011 22:44, Colin Putney <colin(a)wiresong.com> wrote: > On Fri, May 27, 2011 at 2:34 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> Indeed, and in these cases and the other appropriate use cases I'd >> like to see a nicely written, widely used, standardised framework >> precisely so we (I) don't have to write our (my) own. > > FWIW, here's the mock library I use - I think a framework is overkill: > > http://source.wiresong.ca/mc/MockLibrary-cwp.7.mcz Cool, I'll take a look. I suppose I could say "library" or "package" or whatever instead of "framework". It could be as simple as one or two classes. frank

May 27, 2011

Re: [Esug-list] Fwd: Re: Proposal for Mock Objects at ESUG 2011

by Colin Putney

On Fri, May 27, 2011 at 2:34 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > Indeed, and in these cases and the other appropriate use cases I'd > like to see a nicely written, widely used, standardised framework > precisely so we (I) don't have to write our (my) own. FWIW, here's the mock library I use - I think a framework is overkill: http://source.wiresong.ca/mc/MockLibrary-cwp.7.mcz Colin

May 27, 2011

Re: [Esug-list] Fwd: Re: Proposal for Mock Objects at ESUG 2011

by Frank Shearar

On 27 May 2011 21:56, Colin Putney <colin(a)wiresong.com> wrote: > On Fri, May 27, 2011 at 12:42 PM, Frank Shearar <frank.shearar(a)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. > > Not likely. Hernán has been around the block and he speaks from long > experience and deep thinking on software design. If you read his post > a little more carefully, you'll see that he distinguishes between test > doubles in general and mocks as a particular form of test double. He > uses test doubles - you don't get 23,000 tests to run in 7 minutes > without them. It's just *mocks* that are mostly unnecessary. Hernan, I didn't mean to bite your head off. Next time I'll pause a bit longer. > Personally, I find that mocks are *very* useful in a few very specific > situations, but they can cause problems it other situations. They're > like a very specialized tool - invaluable when you need it, but kept > in the bottom of the toolbox and not used very often. Where I find > them useful is in testing communication. For example, I'll use a > MockWritestream to throw an exception if the code under test writes > something unexpected into the stream. It's handy when testing code > that writes out files in a particular format, or communicates with > remote systems over the network. It might also be useful to test > communications across formal module boundaries, where it's > particularly important that a specific protocol be used - eg, for > something like Prevalayer. Indeed, and in these cases and the other appropriate use cases I'd like to see a nicely written, widely used, standardised framework precisely so we (I) don't have to write our (my) own. Anyhow, talk's cheap, and once I've finished my current chunk of work I'll try beat SSpec into shape. frank > My favourite testing pattern is TrivialImplementation. Instead of > using a test double or an expensive "real" object, I often create a > cheap/trivial implementation of the objects that collaborate with the > objects I'm testing. For example, Monticello2 has several repository > classes. There are implementations that store code in a single file, > in a directory of files, on a remote machine via sockets, on a web > server via HTTP etc. There's also a trivial implementation that just > uses an in-memory Dictionary for storage. It's a complete > implementation of the repository protocol, and Monticello can use it > "for real", but it's not as robust as the other kinds of repository. > All the repository implementations, including MemoryRepository, have a > suite of tests that ensure that they work correctly. But when I'm > testing other parts of Monticello that interact with a repository, > those tests use a MemoryRepository. > > I know that BDD folks like to talk about testing behaviour rather than > state, but I don't find the distinction useful. Testing state breaks > the encapsulation of the objects under test, and couples the test too > closely to their internal implementation. Testing behaviour using > mocks *does the same thing*; it just restricts the implementation in a > different way. I find it's better to give the implementation a degree > of freedom by testing "results". Figuring out what result you're > looking for can be difficult - it requires thinking about what a > passing test really tells you. > > Here's an example - let's say we we're testing an implementation of > Set. Here's the version that tests state: > > | set | > set := Set new. > set add: 3. > self assert: (set instVarNamed: 'array') = #(nil nil nil 3 nil) > > Here we test behaviour: > > | set | > mock := MockArray new: 5 > mock expect: (Message selector: #at:put: arguments: #(4 3)). > set := Set withArray: mock. > set add: 3. > > I prefer this approach. It gives the implementation a lot of freedom, > while ensuring that it does what we really want: > > | set | > set := Set new. > set add: 3. > self assert: (set includes: 3). > > In short, I agree with Hernán. Mocks can be useful, but they're often > overused. In most cases, they're unnecessary. > > Colin >

May 27, 2011

Re: [Esug-list] Proposal for Mock Objects at ESUG 2011

by Colin Putney

On Fri, May 27, 2011 at 12:42 PM, Frank Shearar <frank.shearar(a)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. Not likely. Hernán has been around the block and he speaks from long experience and deep thinking on software design. If you read his post a little more carefully, you'll see that he distinguishes between test doubles in general and mocks as a particular form of test double. He uses test doubles - you don't get 23,000 tests to run in 7 minutes without them. It's just *mocks* that are mostly unnecessary. Personally, I find that mocks are *very* useful in a few very specific situations, but they can cause problems it other situations. They're like a very specialized tool - invaluable when you need it, but kept in the bottom of the toolbox and not used very often. Where I find them useful is in testing communication. For example, I'll use a MockWritestream to throw an exception if the code under test writes something unexpected into the stream. It's handy when testing code that writes out files in a particular format, or communicates with remote systems over the network. It might also be useful to test communications across formal module boundaries, where it's particularly important that a specific protocol be used - eg, for something like Prevalayer. My favourite testing pattern is TrivialImplementation. Instead of using a test double or an expensive "real" object, I often create a cheap/trivial implementation of the objects that collaborate with the objects I'm testing. For example, Monticello2 has several repository classes. There are implementations that store code in a single file, in a directory of files, on a remote machine via sockets, on a web server via HTTP etc. There's also a trivial implementation that just uses an in-memory Dictionary for storage. It's a complete implementation of the repository protocol, and Monticello can use it "for real", but it's not as robust as the other kinds of repository. All the repository implementations, including MemoryRepository, have a suite of tests that ensure that they work correctly. But when I'm testing other parts of Monticello that interact with a repository, those tests use a MemoryRepository. I know that BDD folks like to talk about testing behaviour rather than state, but I don't find the distinction useful. Testing state breaks the encapsulation of the objects under test, and couples the test too closely to their internal implementation. Testing behaviour using mocks *does the same thing*; it just restricts the implementation in a different way. I find it's better to give the implementation a degree of freedom by testing "results". Figuring out what result you're looking for can be difficult - it requires thinking about what a passing test really tells you. Here's an example - let's say we we're testing an implementation of Set. Here's the version that tests state: | set | set := Set new. set add: 3. self assert: (set instVarNamed: 'array') = #(nil nil nil 3 nil) Here we test behaviour: | set | mock := MockArray new: 5 mock expect: (Message selector: #at:put: arguments: #(4 3)). set := Set withArray: mock. set add: 3. I prefer this approach. It gives the implementation a lot of freedom, while ensuring that it does what we really want: | set | set := Set new. set add: 3. self assert: (set includes: 3). In short, I agree with Hernán. Mocks can be useful, but they're often overused. In most cases, they're unnecessary. Colin

May 27, 2011

Re: [Esug-list] Fwd: Re: Proposal for Mock Objects at ESUG 2011

by Frank Shearar

On 27 May 2011 21:25, Yann Monclair <yann(a)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(a)10pines.com> wrote: >> >> Hi Frank, >> >> On Fri, May 27, 2011 at 4:42 PM, Frank Shearar <frank.shearar(a)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(a)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(a)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(a)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(a)10Pines.com >>> > site: http://www.10Pines.com >>> > >>> > _______________________________________________ >>> > Esug-list mailing list >>> > Esug-list(a)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(a)10Pines.com >> site: http://www.10Pines.com >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> > >

May 27, 2011

Re: [Esug-list] Fwd: Re: Proposal for Mock Objects at ESUG 2011

by Yann Monclair

> > 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(a)10pines.com> wrote: > Hi Frank, > > On Fri, May 27, 2011 at 4:42 PM, Frank Shearar <frank.shearar(a)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(a)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(a)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(a)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(a)10Pines.com >> > site: http://www.10Pines.com >> > >> > _______________________________________________ >> > Esug-list mailing list >> > Esug-list(a)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(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > >

May 27, 2011

Re: [Esug-list] Fwd: Re: Proposal for Mock Objects at ESUG 2011

by Hernan Wilkinson

Hi Frank, On Fri, May 27, 2011 at 4:42 PM, Frank Shearar <frank.shearar(a)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(a)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(a)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(a)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(a)10Pines.com > > site: http://www.10Pines.com > > > > _______________________________________________ > > Esug-list mailing list > > Esug-list(a)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(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

May 27, 2011

Re: [Esug-list] Fwd: Re: Proposal for Mock Objects at ESUG 2011

by Frank Shearar

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(a)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(a)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(a)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(a)10Pines.com > site: http://www.10Pines.com > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > >

May 27, 2011

Re: [Esug-list] Fwd: Re: Proposal for Mock Objects at ESUG 2011

by Hernan Wilkinson

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(a)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(a)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(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

May 27, 2011