July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] sunit failures vs errors

by Stefan Marr

Hi Camillo: On 10 Jul 2013, at 02:46, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Does anybody here distinguish failures and errors for real when doing TDD? To make your live a little more difficult, I actually introduced an additional type of failure on top of that: blue for still to be implemented. I liked that a lot for prototyping to see all my todos in the test runner in a different pane, and to be able to distinguish between unimplemented stuff, and stuff I just broke again. However, to your actual question, I have not noticed that difference in JUnit, so, I guess, I don't really care for the destination between errors and failures. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Norbert Hartl

Am 10.07.2013 um 08:15 schrieb "Torsten Bergmann" <astares(a)gmx.de>: > Camillo wrote: >> Does anybody here distinguish failures and errors for real when doing TDD? > > Yes, it has a special meaning AND is very helpfull - ESPECIALLY when you start with tests first (XPStyle): > Usually one writes the tests and then you try to get them from red over yellow to > green: > > red: there is a real error, for instance a message is not yet implemented (maybe only the test was written > and one uses the debugger and the "Create" functionality to create the calls) > > yellow: the basic calls are there/messages implemented and working (no DNU) but an expectation is not yet > met since an assertion fails > > green: everything is OK > > > Or to quote Kent Beck: http://www.xprogramming.com/testfram.htm > > <quote> > "Failures and Errors > > The framework distinguishes between failures and errors. A failure is an anticipated problem. When you write tests, you check for expected results. If you get a different answer, that is a failure. An error is more catastrophic, a error condition you didn't check for." > </quote> > That is funny. I was thinking the same when replying to Cami. I wanted to write something like an error being more catastrophic... but then I was thinking about it and I'm not sure anymore. Sure they are different...wait...are they? The longer I think about it the lesser I'm convinced that it needs to stay like it is. Especially in the case of should:raise: where a piece of broken code triggers only a failure. Just to be correct...No Cami...that doesn't mean it needs to be changed either :) Norbert > Please keep it separated, it is very usefull. > >> Besides the complexity added to the testing framework it is a burden for newcomers. > > Learning about Pragmas, Methods, Classes, Debugger, marking expected failures, ... is also a burden for newcomers. > Will we throw them out? No! > > SUnit is still really simple and a pleasure to work with! > > Thx > Torsten > > >

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Norbert Hartl

I use them. I always fix the red tests first because they are mostly easier to fix and some of them lead to yellow tests. Maybe not that convincing but I feel the distinction between fail and error is good. Will think about it more. Am 10.07.2013 um 02:46 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > Does anybody here distinguish failures and errors for real when doing TDD? > > I do not really see the point of separating them. > Besides the complexity added to the testing framework it is a burden for newcomers. > > I personally just see: > 1) test passes => green, ok > 2) test doesn't pass => red, not ok > > Apparently that has been done in JUnit4 http://www.devx.com/Java/Article/31983/0/page/2

July 10, 2013

sunit failures vs errors

by Torsten Bergmann

Camillo wrote: >Does anybody here distinguish failures and errors for real when doing TDD? Yes, it has a special meaning AND is very helpfull - ESPECIALLY when you start with tests first (XPStyle): Usually one writes the tests and then you try to get them from red over yellow to green: red: there is a real error, for instance a message is not yet implemented (maybe only the test was written and one uses the debugger and the "Create" functionality to create the calls) yellow: the basic calls are there/messages implemented and working (no DNU) but an expectation is not yet met since an assertion fails green: everything is OK Or to quote Kent Beck: http://www.xprogramming.com/testfram.htm <quote> "Failures and Errors The framework distinguishes between failures and errors. A failure is an anticipated problem. When you write tests, you check for expected results. If you get a different answer, that is a failure. An error is more catastrophic, a error condition you didn't check for." </quote> Please keep it separated, it is very usefull. >Besides the complexity added to the testing framework it is a burden for newcomers. Learning about Pragmas, Methods, Classes, Debugger, marking expected failures, ... is also a burden for newcomers. Will we throw them out? No! SUnit is still really simple and a pleasure to work with! Thx Torsten

July 10, 2013

Re: [Pharo-dev] should:raise:description:

by Max Leske

On 09.07.2013, at 23:28, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-07-09, at 21:23, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 9 July 2013 19:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> I continue my rant with should:raise:description: >>> >>> a) self should: [ Error signal: 'error message' ] raise: Halt description: 'message'. >>> b) self should: [ 1 + 2 ] raise: Halt description: 'message'. >>> >>> In the first case you do not get the 'message' but 'error message'. >>> In the second case you get the 'message'. >>> >>> Does the description make sense in this case? >>> 1. if you signal Halt everything is fine >>> 2. Every other case is a failure >>> 3. In case a) an internal failure happens so the test fails anyway, fine, but no description >>> 4. A strange? case where the tests actually DO pass but we nevertheless want to print a description. >>> >>> Can anybody give me a convincing case for 4? >>> >>> Sorry, after this I will stop :D >> >> In case (a) I would actually expect to see something like: "message. >> Unexpected Error raised: 'error message'". >> >> In case (b) I'd want to see "message: no Halt raised" >> >> I can't think of why you would want a description for a success case, >> so #4 just seems weird! > > exactly! :) I agree on that ;). Now the question is on how to properly fix this > for debugging. Since you actually want to debug on the unexpected Exception in > case a)... YESSSS!! That's about the thing I hate the most about SUnit: if a testrun fails because #should: fails, the signaler context is gone. That's SO ANNYOING! > > I'll check my magic box..

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Camillo Bruni

On 2013-07-10, at 06:35, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Wed, Jul 10, 2013 at 2:46 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> Does anybody here distinguish failures and errors for real when doing TDD? > > > I don't and I would like to see if both can be merged. 2 pomodoros for a prototype 1 day for a clean implementation ;)

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Damien Cassou

On Wed, Jul 10, 2013 at 2:46 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > Does anybody here distinguish failures and errors for real when doing TDD? I don't and I would like to see if both can be merged. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 10, 2013

sunit failures vs errors

by Camillo Bruni

Does anybody here distinguish failures and errors for real when doing TDD? I do not really see the point of separating them. Besides the complexity added to the testing framework it is a burden for newcomers. I personally just see: 1) test passes => green, ok 2) test doesn't pass => red, not ok Apparently that has been done in JUnit4 http://www.devx.com/Java/Article/31983/0/page/2

July 10, 2013

Re: [Pharo-dev] Some Spec questions

by Benjamin

On Jul 9, 2013, at 11:35 PM, Clara Allende <clari.allende(a)gmail.com> wrote: > Hi folks, while working on the new debugger, I've come up with some questions... > > *is there any other implementation for dynamic widgets other that the current one? I do not get your question ... > > *right now the toolbar is a static widget, and I would like to have a dynamic one to filter out the actions that should not be available (which are a subset of the default ones). Would it make sense to regenerate the toolbar everytime the selection changes? Is there any other approach I should consider? It may make sense to dynamically regenerate the toolbar (or at least remove only what needs to be removed, add only what needs to be added). Then you should also think in term of user experience. Having things changing may be disturbing and counter productive :) Ben > Thanks in advance! > Cheers, > Clari > >

July 9, 2013

Re: [Pharo-dev] thisContext usecases

by Eliot Miranda

On Tue, Jul 9, 2013 at 1:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 July 2013 10:15, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello pharoers, > > > > Recently I have been looking at the Pharo thisContext capabilities, in > order > > to perhaps one day in the far future edit its implementation with the > Pharo > > dev team. Nothing is planned or confirmed, it is just to discuss. > > > > A context has instances variables (method closureOrNil receiver stackp > > sender pc) and holds the arguments and temporaries. > > > > Now I'd like to know what context's state do we modify, and what states > are > > just internal representations ? > > > > For example, it seems that you can do 'thisContext receiver: #foo', but > you > > cannot with Cog. > > > > SomeClass>>foo > > thisContext receiver: #foo. > > ^ self > > > > In workspace, evaluating: > > 1 to: 5 do: [:i | Transcript show: SomeClass new foo ] > > > > Transcript result (with Cog): > > foo > > foo > > a SomeClass > > a SomeClass > > a SomeClass > > > > Transcript result (with Stack or Vanilla): > > foo > > foo > > foo > > foo > > foo > > > > Now as no one has ever complained, I guess this feature is not used. > > > > As far as I know, the real use cases of the context seems to be: > > - setting and gettings temporaries > > - setting and getting the sender of a context > > - setting and getting the pc > > - getting method, closureOrNil, receiver, stackp, arguments but NOT > setting > > them > > > > Now setting the sender of a context seems to be used only in two cases: > > - continuations (as seaside continuations) > > - exception implementation > > > > So imagine that in the future you would have a context that can be > accessed > > in read-only, where you could only: > > - set the temporaries (but not arguments) > > - set the pc (or something equivalent, as set the currently executed ast > > node) > > - use continuations (exceptions can be implemented on top of > continuations) > > > > I would like to know if there are things that you do now and that you > would > > not be able to do with a context like that. For non meta developer (like > > enterprise app developer) I guess it will not change anything, but I > want to > > know if you implemented a framework as seaside, does it requires other > > things from the context and why ? > > > > To my thinking playing with pc is awfully evil, it should be > read-only, only to allow debugger > to map it to source code. Same goes for stack pointer. > There are good uses for this I just used it to implement basic-block coverage for methods. One can use it for exception handling (mustBeBoolean etc). I'm always wary of introducing restrictions when the system has worked fine without them for years. One exception recently was in adding bounds checking to CompiledMethod>>at:put: so one could not change arbitrary bytes in the literals via at:put:. But this was adding safety, not adding a restriction. I see no harm in allowing one to assign the pc. It is unsafe, and the system will likely crash if you get it wrong. But it is also potentially useful (e.g. I've used it to do a prototype of tail-recursion elimination). So let's be laissez faire, unless the freedoms in question really do only do harm. > > Setting receiver is less evil and it may work, if receiver belongs to > same inheritance chain > as compiled method's class. But it should not be set without checking this. > > And for method's temps, it is fine. > > > Thanks for answering, > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

July 9, 2013