- Esug-list - lists.esug.org

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

by Stéphane Ducasse

+ 1 Already added to the program draft. I will publish it soon. Stef On May 27, 2011, at 3:28 PM, John O'Keefe wrote: > Dennis - > > Yes, I would very much like to hear what you've done with Mock Objects. Niall makes some interesting points in his note about alternatives and I think it would be good to explore these as part of your presentation since they seem to be related to why we haven't seen mocks used more commonly in Smalltalk. > > John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc. > Skype: john_okeefe2 Mobile: +1 919 417-3181 (Business hours USA Eastern Time zone (GMT -5)) > john_okeefe(a)instantiations.com > http://www.instantiations.com > VA Smalltalk...Onward and Upward! > > > On Fri, May 27, 2011 at 12:36 AM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > 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 > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

May 28, 2011

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

by stephane ducasse

I ordered it :) On May 27, 2011, at 1:22 PM, simondenier wrote: > That's interesting. I recently started to use Cucumber with Rails, which > looks like another step in BDD with specs written in look-alike natural > language. Hard to beat in terms of readibility, even with the Smalltalk > syntax. But that's another topic. > http://cukes.info/ > > On topic I started to read the GOOS book written by two pioneers of mocks, > and I think it's a recommended reading on the topic of objects + TDD + mock. > Just read the first chapters for now but it's in line with my own conception > of objects yet offers some interesting insights about design. I think Tim > McKinnon which has been a regular participant of Smalltalk events in the > past years might have a word or two on the topic :) > > http://www.growing-object-oriented-software.com/ > > -- > View this message in context: http://forum.world.st/Proposal-for-Mock-Objects-at-ESUG-2011-tp3554367p3554… > Sent from the ESUG mailing list archive at Nabble.com. > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

May 28, 2011

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

by Dennis Schetinin

Thank you very much for all the replies, comments, criticism, ideas, references… inspiration! I really didn't expect such an interesting discussion to go. And now I clearly see the topic is questionable and worth discussion. I'll for sure explain my point further here and hopefully at conference, just have to think and structure my thoughts before a bit. Once again, thank you! :) -- Dennis Schetinin

May 28, 2011

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

by Yoshiki Ohshima

At Fri, 27 May 2011 19:53:46 -0300, Martin Dias wrote: > > 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.) > > Sounds great! Do you have it in a public repository? Sure. It is here: https://github.com/yoshikiohshima/SqueakBootstrapper The system is just enough to load a compiler so it does not handle curly braces nor pragmas or primitives. But By setting the path to the Squeak VM in the Makefile, it should run on major platforms where the VM takes command line arguments. -- Yoshiki

May 28, 2011

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

by Martin Dias

On Fri, May 27, 2011 at 7:37 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > 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.) > Sounds great! Do you have it in a public repository? > > -- Yoshiki > > _______________________________________________ > 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

> > > Hernan, I didn't mean to bite your head off. Next time I'll pause a bit > longer. > don't worry! It is very common to get passionated about these things and I like that :-), it means we care about them. I'd like to see the talk at Esug. Bye, Hernan. > > > 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 > > > -- *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] 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