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

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

by Göran Krampe

On 05/31/2011 04:59 PM, Frank Shearar wrote: > 2011/5/31 Göran Krampe<goran(a)krampe.se>: >> So refreshingly to see someone that *also* notes that testing using mocks >> actually break encapsulation. Thank you, thank you... > > Or to rephrase, "documenting the precise nature of the colloboration > between an object and its context documents that precise nature." > > In Colin's example, Set's collaboration with Array is purely an > implementation detail and, as he notes, testing the implementation - > whether checking that Set stores the value in the array, or what > messages Set might send to Array - hurts you. > > I fail to see how that makes mocks bad. Unless you're railing against > hype? In which case, I agree: there ain't no such thing as a free > lunch, there is no silver bullet, etc etc. Well, yes, railing against hype. But also railing against writing tests that work from "the inside" by using mocks. It is of course a matter of taste, style and in the end weighing pros and cons. But I have seen too much use of mocks that end up making the tests purely mirror the implementation - so even the slightest internal modification would break the test. regards, Göran

May 31, 2011

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

by Mariano Martinez Peck

On Sun, May 29, 2011 at 9:07 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> wrote: > At Sun, 29 May 2011 20:52:45 +0200, > Mariano Martinez Peck wrote: > > > > On Sun, May 29, 2011 at 8:45 PM, Yoshiki Ohshima <yoshiki(a)vpri.org> > wrote: > > > > At Sat, 28 May 2011 09:33:27 +0200, > > Stéphane Ducasse wrote: > > > > > > Yoshiki > > > > > > if you want to help testing, improving fuel you are welcome. > > > The idea is to make it fast fast fast without vm support. > > > > Yeah. The reason for example I went to pad data to 4 bytes > > > > What do you mean by padding data to 4 bytes? I don't understand :( > > Say a string has length of 5 ('abcde'), the data in file for it > would be "97 98 99 100 101 0 0 0". > > Sorry but I don't understand then how that is related to "The reason for example I went to pad data to 4 bytes was that there may be a clever trick I may be able to do to read data into arrays "directly" and stuff, but did not get around implementing it." > > was that > > there may be a clever trick I may be able to do to read data into > > arrays "directly" and stuff, > > > > what do you mean by that? like ImageSegment does? I mean, include also > object headers in the stream and then avoid to recreate objects (using > #basicNew) ? > > Not like ImageSegment, but more like #hackBits: reading from file > into a string object of right size. I am not sure if I understand. For some kind of objects (those that are variable) we store first its size and then at materialization time we directly create an object of that size using #basicNew: but I guess you are talking about something else. > For pointer arrays and actual > literal fields, I am not sure I can apply this however. > > I would not put object headers, as you would agree^^; > > -- Yoshiki > -- Mariano http://marianopeck.wordpress.com

May 31, 2011

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

by Dennis Schetinin

First of all, I'm sorry for my English. (And I'll appreciate it very much if someone will point to mistakes of any kind in the following text.) I attempted to analyze and structure comments, questions and ideas presented in the thread and I think I found one thing that can be a starting point for the discussion (despite the fact the discussion already started… away back). I've got a strong feeling (I've got it several years ago and had a number of evidences, including several in this thread) that there are (at least) two very different (if not opposite) points of view on mock objects… and it seems to me, the root of this divergence is even deeper and more general — understanding of TDD. So, I think I have to explain my point of view. (Telling "my" here I claim to be an author of all errors, misinterpretations and nonsenses I'll present. But all the good, reasonable and interesting things were invented by other (clever) people.) So, why and how did I dare to claim TDD is not really popular among Smalltalkers? Because I still believe tests can drive (nearly) all stages of development: not just coding, but also design and even analysis (at least to clarify and formalize results of analysis). But I rarely (if ever) see any artifacts (tests of the kind). Perhaps I'm wrong, but most of the tests I saw were more "acceptance" tests, perhaps even written afterwards. Once again: very likely I'm wrong (and I'll be glad to be, actually). Why is it important for me to use TDD? Because, as a bad programmer, I need a help. I have a lot of things I must think about during development (won't enumerate, we all know them), so I want a tool that helps me not to think too much — at least, at the points where it is possible at all. (If I misinterpret the word "driving" here, please let me know.) Thus, if I write a line of code that is not directly(!) driven by a test, I don't TDD. If I make some up-front design I'm not actually test-driven. Even, if I simply go few steps designing top-down without tests at a very small single stage of development, TDD is broken. If you think it is too extreme and strict — ok, let's talk about "seamless TDD" vs., say, "partial TDD". (Yes, I know about steps of variable size during TDD etc. But I still think it's a bit another thing. Let's judge a bit later…) So, considering an example by Colin Putney: | set | set := Set new. set add: 3. self assert: (set includes: 3). vs | set | mock := MockArray new: 5 mock expect: (Message selector: #at:put: arguments: #(4 3)). set := Set withArray: mock. set add: 3. Isn't it obvious mocking array here is an overkill and the first test is better? For sure it is. But why? Because there's actually no development in the 1st test. Otherwise, what is it for: #add: or #includes:? Which feature this test makes me to add to the system-under-test (the Set)? I must select, I must think, thus I'm not driven by the test. Consider also (slightly) another issue: here we have a ready-to-use inner collection for the Set. But if I have no yet? Isn't it a common and very frequent situation during development: I have to implement a (sub)system that comprises several objects working together? (I think I don't have to provide examples here to prove.) Which one should I implement first? I don't know, I have to explore. I must analyze the system, i.e. divide it into subcomponents, find the ones independent and start by implementing them first. But what is this process, I've just described? It's a top-down up-front design. Is it test-driven? Obviously, no. Do I have an alternative? Yes, I can use mocks. With Mocketry I could write: SetTests >> testStoresElementsInInnerCollection [:collection | set := Set withArray: collection. [set add: #element] should strictly satisfy: [collection add: #element]] runScenario Of course, this is a very early step of development, as I'll have to implement an efficient algorithm to check, if element exists in the set before adding it… And with mocks it is very likely I'll be driven to implement it as a pluggable object. Probably, this can make Set a bit more flexible, doesn't it? On the other hand, it can introduce unnecessary complexity. Apparently, this is a good example to explore it further… While I must admit technique of mock object is not a silver bullet, and must be used carefully… just as any other tool. So… Conclusion 1: Yes, mock objects is a specific tool for specific situations. But as for me, I meet these specific situation almost as frequently, as other, non-specific(?) circumstances. Conclusion 2: I think mocks should be used, first of all, to discover different aspects of functionality and distribute it among various objects. (Documentation, optimization, etc. goes later… if goes at all…) When I start to work on a new feature, I first try to write an acceptance test. But I never can implement it 'as is'. And I hate to leave it red or mark it as ignored (in any way). So I try to transform it into something I can implement easily and fast. And often this leads me to a test with mocks. This make me to divide complex functionality into smaller blocks and factor them out to collaborators. The trick is to make those objects to behave (one-by-one and altogether)… But that's another (and big) topic. -- Dennis Schetinin

May 31, 2011

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

by Frank Shearar

2011/5/31 Göran Krampe <goran(a)krampe.se>: > Hey! > > Stumbled into this thread but just HAVE to respond... Snipping heavily here: > > On 05/27/2011 11:11 PM, Colin Putney wrote: >> >> without them. It's just *mocks* that are mostly unnecessary. > > Amen! I have been thinking the rest of the world had gone mad... > >> 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. > > Right. > > [SNIP of good stuff] >> >> 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. > > So refreshingly to see someone that *also* notes that testing using mocks > actually break encapsulation. Thank you, thank you... Or to rephrase, "documenting the precise nature of the colloboration between an object and its context documents that precise nature." In Colin's example, Set's collaboration with Array is purely an implementation detail and, as he notes, testing the implementation - whether checking that Set stores the value in the array, or what messages Set might send to Array - hurts you. I fail to see how that makes mocks bad. Unless you're railing against hype? In which case, I agree: there ain't no such thing as a free lunch, there is no silver bullet, etc etc. frank

May 31, 2011

Looking for a PhD position

by Stéphane Ducasse

Hi guys Here is a student that is looking for a PhD grant.... I do not meet him but just forward to you his profile. Stef Dear smalltalkers, I am a student in computer sciences at the Henri Poincaré University of Nancy (France) and I am currently studying for a master's degree called "Software : theory, methods and engineering". I am looking for a Ph.D position in programming language design, component-based programming or more generally in software engineering. Please find enclosed my CV. I am at your disposal to provide any other relevant information. Cordially, Camille Teruel

May 31, 2011

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

by Göran Krampe

Hey! Stumbled into this thread but just HAVE to respond... Snipping heavily here: On 05/27/2011 11:11 PM, Colin Putney wrote: > without them. It's just *mocks* that are mostly unnecessary. Amen! I have been thinking the rest of the world had gone mad... > 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. Right. [SNIP of good stuff] > 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. So refreshingly to see someone that *also* notes that testing using mocks actually break encapsulation. Thank you, thank you... regards, Göran

May 31, 2011

Re: [Esug-list] Recherche de thèse

by Stéphane Ducasse

au lieu que cela soit moi qui envoie un mail peut etre que cela serait mieux que tu le fasses. il y a esug-list ESUG Mailing list <esug-list(a)lists.esug.org> si tu ne peux pas publier alors ecrit un petit mail et je ferais un forward. sinon tu peux contacter oscar nierstrasz (universite de berne), michele lanza (universite de lugano - plus sur la visualization), theo d'hont (belgique), noury bouraqadi, Stef On May 31, 2011, at 9:52 AM, camille teruel wrote: > Bonjour M.Ducasse, > > En effet j'ai oublié de remettre la partie stage, voici le CV corrigé. > L'article, en tant que "position paper", n'a pas été publié dans les actes de la conférence, mais je l'ai quand même mentionné étant donné que c'est ma seule publication à l'heure actuelle... > > Cordialement, > Camille Teruel > > PS: J'ai regardé un peu plus en profondeur Smalltalk hier soir, du coup, je retire ce que j'ai dit, c'est un langage objet dynamique presque comme les autres. Beaucoup de monde parle de Ruby comme d'un mini-Smalltalk et de l'objet dynamique reste de l'objet dynamique alors dans ma tête c'était Ruby=Smalltalk=Groovy=..., mais au final c'est assez différent. > <cv_teruel.pdf>

May 31, 2011

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

by stephane ducasse

Yes if you do not use the same vm , the problem is that you will compare apple and orange. Stef > > > On Mon, May 30, 2011 at 8:27 AM, Paolo Bonzini <bonzini(a)gnu.org> wrote: > On 05/29/2011 08:51 PM, Mariano Martinez Peck wrote: > But if I compare the serializing > time and deserializing time of my thing, writing is about twice slower > than reading. > > > Yes, I think that is the normal and more or less the expected difference > right now. > > > Do you want to make some comparisons with the GNU Smalltalk ObjectDumper? I can help, or I can even make some comparisons myself if you give me some test Fuel code and an image to test with. > > > Hi Paolo. ObjectDumper was one of the serializers that we wanted to analyze also to get ideas and compare. This is why once I tried to install GNU Smalltalk in my machine but I couldn't so I give up. > The problem to compare ObjectDumper is that we need to be able to run both in the same Dialect/VM. Otherwise the difference of the dialect or VM can change the results a lot. > > Sorry for the offtopic but is there an easy way to install GNU Smalltalk in a Mac OS 10.6.7 ? > > Thanks > > > -- > Mariano > http://marianopeck.wordpress.com > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

May 30, 2011

Re: [Esug-list] Don't forget: Your talks at ESUG

by Niall Ross

1) See http://www.esug.org/Conferences/2011/Submissions-for-2011 2) It's in Edinburgh, SCOTLAND !!!!! http://www.youtube.com/watch?v=rNu8XDBSn10 (or read my 'lighthearted local history' page) stephane ducasse wrote: >19th International Smalltalk Joint Conference - Call for Contributions > > Edinburgh, England > August 20-26 2011; Camp Smalltalk September 20-21 > http://esug.org/Conferences/2011/ > >This call includes: > Developer program > Free ESUG tickets > International Workshop http://esug.org/Conferences/2011/International-Workshop-on-Smalltalk-Techno… > Student Volunteer http://esug.org/Conferences/2011/Student+Volunteers+program > Camp Smalltalk: Saturday 20th - Sunday 21st August 2011. > ESUG conference: Monday 22nd - Friday 26th August 2011. > > >This year will be held the > - 7th edition of the Innovation Technology Awards where prizes will be > awarded to authors of best pieces of Smalltalk-related projects > - an international workshop on Smalltalk and dynamic languages > http://www.esug.org/wiki/pier/Conferences/2011/International-Workshop-on-Sm… > > > - ESUG will offer 10 free entrance tickets. > To get a free ticket you should send a mail to the esug board (board(a)esug.org) > Subject: [ESUG 2011 Free entrance] + your name > And you should write a small motivation. > > >You can support the ESUG conference in many different ways: > > * Sponsor the conference. New sponsoring packages are described at > http://www.esug.org/supportesug/becomeasponsor/ > * Submit a talk, a software or a paper to one of the events. See > below. > > * Attend the conference. We'd like to beat the previous record of > attendance (156 participants at Brest and 170 people at Amsterdam, 150 at Barcelona)! > > * Students can get free registration and hosting if they enroll > into the the Student Volunteers program. See below. > >Developers Forum: International Smalltalk Developers Conference >------------------------------------------------------------------------ >This year we are looking for YOUR experience on using Smalltalk. >In addition, we are looking for tutorials. The >list of topics includes, but is not limited to the following: > >* XP practices >* Development tools >* Experience reports >* Model driven development >* Web development >* Team management >* Meta-Modeling >* Security >* New libraries & frameworks >* Educational material >* Embedded systems and robotics >* SOA and Web services >* Interaction with other programming languages > >Submissions due on 1 July 2010 >Notification of acceptance on 5 of July 2010 >More information at http://www.esug.org/conferences/2011 > >How to submit? >------------------ >Pay attention: the places are limited so do not wait till the last >minute to apply. Prospective presenters should submit a request to >board(a)esug.org AND stephane.ducasse(a)free.fr >following the template below. Please use this template since the >emails will be automatically processed! > >Subject: [ESUG 2011 Developers] + your name > >First Name: > >Last Name: > >Email where you can always be reached: > >Title: > >Abstract: > >Bio: > >Any presentation not respecting this form will be discarded automatically > > >Innovation Technology Award >------------------------------------------------------------------------ >We are proud to announce the 6th Innovation Technology Awards. The >top 3 teams with the most innovative software will receive, >respectively, 500 Euros, 300 Euros and 200 Euros during an awards >ceremony at the conference. Developers of any Smalltalk-based >software are welcome to compete. This year we will request 3-5min videos. >More information at http://www.esug.org/Conferences/2011/Innovation+Technology+Awards > > >Student Volunteer Program >------------------------------------------------------------------------ >If you are a student wanting to attend ESUG, have you considered >being a student volunteer? Student volunteers help keep the >conference running smoothly; in return, they have free >accommodations, while still having most of the time to enjoy the >conference. >More information at >http://www.esug.org/conferences/2011 >http://www.esug.org/Conferences/2011/Student+Volunteers+program > >We hope to see you there and have fun together. > > >Ze ESUG board_______________________________________________ > > >_______________________________________________ >Esug-list mailing list >Esug-list(a)lists.esug.org >http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ > > > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

May 30, 2011

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

by Paolo Bonzini

On 05/30/2011 10:02 AM, Mariano Martinez Peck wrote: > The problem to compare ObjectDumper is that we need to be able to run > both in the same Dialect/VM. Otherwise the difference of the dialect > or VM can change the results a lot. That's true. > Sorry for the offtopic but is there an easy way to install GNU > Smalltalk in a Mac OS 10.6.7 ? With 3.2.4 and MacPorts it should be easy. You need to install the libsigsegv port first. It may not work right away if your compiler doesn't look in MacPorts paths. You can preempt the issue with an extra option to the configure script: ./configure --with-system-libsigsegv=/opt/local/lib --prefix=/opt/local make sudo make install (or /opt/local/lib64, I don't know :)). ObjectDumper should be easy to port to Pharo. Something like gst-convert -f gst -F squeak /opt/local/smalltalk/kernel/ObjDumper.st | tr '\n' '\r' > objdumper.sq should be a good start. Check out category "private - binary I/O", that's where changes might be made. The resulting streams should be portable between dialects, though I've never tried. Testcases are old so they have not been converted to SUnit, but I'm sure someone in the GNU Smalltalk community can help. :> Lastly, it was written entirely by me, so I can relicense parts of it if required. Contact me off-list if you are interested. HTH, Paolo

May 30, 2011