- Pharo-dev - lists.pharo.org

[Pharo-project] why isEmptyOrNil is not defined in Object?

by StÃ©phane Ducasse

Hi guys I'm puzzled and probably need food. but why isEmptyOrNil is not defined in Object? because right now if a variable is '' or nil or something else I cannot use it. Stef

July 19, 2011

[Pharo-project] [update 1.4] #14049

by StÃ©phane Ducasse

14049 ----- Merging latest ring core fixes + tests with veronica.

July 19, 2011

Re: [Pharo-project] [update 1.3] #13287

by StÃ©phane Ducasse

Thanks lukas. Our goal is to create a really good system. We do not say that we know everything but this is important to try and build the best system we can. And feedback/discussions/critics are important so that we all make progress. Again Pharo is our system not mine. Stef On Jul 18, 2011, at 8:44 PM, Lukas Renggli wrote: > Great, thank you for the quick fix. > > On Monday, 18 July 2011, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> 13287 >> ----- >> >> - Issue 4528: Exception on:fork: enhancement. Thanks Igor Stasenko and Lukas Renggli for the idea. >> >> - Issue 4529: Announcement delivery breaks if last subscriber is curtailed. Thanks Henrik Johanssen. >> > > -- > Lukas Renggli > www.lukas-renggli.ch >

July 19, 2011

Re: [Pharo-project] Stubbing class-side methods

by Denis Kudriashov

I think not. This way is substitution of method literal. But "self sends" stubbing required anonimous subclass creation with required methods overrides. 2011/7/19 Dennis Schetinin <chaetal(a)gmail.com> > Can we test self sends this way? > > > 2011/7/19 Denis Kudriashov <dionisiydk(a)gmail.com> > >> I should add it to Mocketry. >> >> 2011/7/19 Sean P. DeNigris <sean(a)clipperadams.com> >> >> Ah, so the lookups are done once when the method is compiled and then >>> stored >>> in the CompiledMethod... >>> >>> My vision is to write something like: >>> cannedNow := DateAndTime stub: #now; andReturn: [ DateAndTime >>> year: 2011 >>> month: 12 day: 24 hour: 12 minute: 34 second: 55 ]. >>> testableClass := MyClass usingDouble: cannedNow. >>> >>> The first line seems easy, and for the second line, I have so far (very >>> rough, but working): >>> >>> | class copy | >>> class := MyClass. >>> copy := MyClass copy. >>> >>> copy methods do: [ :m | | classRef | >>> (m hasLiteralSuchThat: [ :l | ((l isKindOf: Association) >>> and: [ l key = >>> #DateAndTime])]) >>> ifTrue: [ | newMeth refIndex | >>> newMeth := copy methodDictionary at: m >>> selector put: m copy. >>> refIndex := newMeth >>> indexOfLiteralSuchThat: [ :l | ((l isKindOf: >>> Association) and: [ l key = #DateAndTime])]. >>> newMeth literalAt: refIndex put: >>> #DateAndTime->MockedClass ] ]. >>> ^ copy. >>> >>> Where CompiledMethod>>indexOfLiteralSuchThat: aBlock >>> "Answer the literal index of the argument, literal, or zero if >>> none." >>> 2 to: self numLiterals - 1 "exclude superclass + >>> selector/properties" >>> do: >>> [:index | >>> (aBlock value: (self objectAt: index)) ifTrue: [^index - >>> 1]]. >>> ^0 >>> >>> Thanks again. >>> Sean >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Stubbing-class-side-methods-tp3674065p3676637.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >> > > > -- > Dennis Schetinin >

July 19, 2011

Re: [Pharo-project] Stubbing class-side methods

by Dennis Schetinin

Can we test self sends this way? 2011/7/19 Denis Kudriashov <dionisiydk(a)gmail.com> > I should add it to Mocketry. > > 2011/7/19 Sean P. DeNigris <sean(a)clipperadams.com> > > Ah, so the lookups are done once when the method is compiled and then >> stored >> in the CompiledMethod... >> >> My vision is to write something like: >> cannedNow := DateAndTime stub: #now; andReturn: [ DateAndTime year: >> 2011 >> month: 12 day: 24 hour: 12 minute: 34 second: 55 ]. >> testableClass := MyClass usingDouble: cannedNow. >> >> The first line seems easy, and for the second line, I have so far (very >> rough, but working): >> >> | class copy | >> class := MyClass. >> copy := MyClass copy. >> >> copy methods do: [ :m | | classRef | >> (m hasLiteralSuchThat: [ :l | ((l isKindOf: Association) >> and: [ l key = >> #DateAndTime])]) >> ifTrue: [ | newMeth refIndex | >> newMeth := copy methodDictionary at: m >> selector put: m copy. >> refIndex := newMeth indexOfLiteralSuchThat: >> [ :l | ((l isKindOf: >> Association) and: [ l key = #DateAndTime])]. >> newMeth literalAt: refIndex put: >> #DateAndTime->MockedClass ] ]. >> ^ copy. >> >> Where CompiledMethod>>indexOfLiteralSuchThat: aBlock >> "Answer the literal index of the argument, literal, or zero if >> none." >> 2 to: self numLiterals - 1 "exclude superclass + >> selector/properties" >> do: >> [:index | >> (aBlock value: (self objectAt: index)) ifTrue: [^index - >> 1]]. >> ^0 >> >> Thanks again. >> Sean >> >> >> -- >> View this message in context: >> http://forum.world.st/Stubbing-class-side-methods-tp3674065p3676637.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > -- Dennis Schetinin

July 19, 2011

Re: [Pharo-project] Stubbing class-side methods

by Denis Kudriashov

I should add it to Mocketry. 2011/7/19 Sean P. DeNigris <sean(a)clipperadams.com> > Ah, so the lookups are done once when the method is compiled and then > stored > in the CompiledMethod... > > My vision is to write something like: > cannedNow := DateAndTime stub: #now; andReturn: [ DateAndTime year: > 2011 > month: 12 day: 24 hour: 12 minute: 34 second: 55 ]. > testableClass := MyClass usingDouble: cannedNow. > > The first line seems easy, and for the second line, I have so far (very > rough, but working): > > | class copy | > class := MyClass. > copy := MyClass copy. > > copy methods do: [ :m | | classRef | > (m hasLiteralSuchThat: [ :l | ((l isKindOf: Association) > and: [ l key = > #DateAndTime])]) > ifTrue: [ | newMeth refIndex | > newMeth := copy methodDictionary at: m > selector put: m copy. > refIndex := newMeth indexOfLiteralSuchThat: > [ :l | ((l isKindOf: > Association) and: [ l key = #DateAndTime])]. > newMeth literalAt: refIndex put: > #DateAndTime->MockedClass ] ]. > ^ copy. > > Where CompiledMethod>>indexOfLiteralSuchThat: aBlock > "Answer the literal index of the argument, literal, or zero if > none." > 2 to: self numLiterals - 1 "exclude superclass + > selector/properties" > do: > [:index | > (aBlock value: (self objectAt: index)) ifTrue: [^index - > 1]]. > ^0 > > Thanks again. > Sean > > > -- > View this message in context: > http://forum.world.st/Stubbing-class-side-methods-tp3674065p3676637.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

July 19, 2011

Re: [Pharo-project] Mocketry?

by Dennis Schetinin

Yes, you can write it this way: SomeTests >> testXXX [:mock1 :mock2 | [mock1 someMessage. mock2 someMessage2] should strictly satisfy: [mock1 someMessage willReturn: 'some'. mock2 someMessage2] ] runScenario 2011/7/19 Sean P. DeNigris <sean(a)clipperadams.com> > > Dennis Schetinin wrote: > > > > It means you can just run Mocketry tests with SUnit test runner > > > > I mean how does one use mocks specifically with SUnit. For example, from > the > HelpBook: > > [:mock1 :mock2 | [mock1 someMessage. mock2 someMessage2] > should strictly satisfy: > [mock1 someMessage willReturn: 'some'. > mock2 someMessage2]] > runScenario > > Where do I put that? Drop the whole thing including the #runScenario into a > #testXxx or what? > > Thanks. > Sean > > -- > View this message in context: > http://forum.world.st/Mocketry-tp3555258p3677175.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Dennis Schetinin

July 19, 2011

Re: [Pharo-project] Mocketry?

by Sean P. DeNigris

Dennis Schetinin wrote: > > It means you can just run Mocketry tests with SUnit test runner > I mean how does one use mocks specifically with SUnit. For example, from the HelpBook: [:mock1 :mock2 | [mock1 someMessage. mock2 someMessage2] should strictly satisfy: [mock1 someMessage willReturn: 'some'. mock2 someMessage2]] runScenario Where do I put that? Drop the whole thing including the #runScenario into a #testXxx or what? Thanks. Sean -- View this message in context: http://forum.world.st/Mocketry-tp3555258p3677175.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 19, 2011

Re: [Pharo-project] Mocketry?

by Dennis Schetinin

It means you can just run Mocketry tests with SUnit test runner, no modifications needed. Just as with "ordinary" tests, all verifications are performed "at place": SomeObjectTests >> testDoesSomething * 2 + 2 should equal: 4. *"Here it passes" * 2 + 2 should equal: 5. *"Here it fails" "Nothing else is needed" â¦Or, did I misunderstood your question? 2011/7/19 Sean P. DeNigris <sean(a)clipperadams.com> > I read that Mocketry is compatible with the SUnit test runner. How would > one > use it like this? call #verify at the end of a TestCaseSubclass>>testXxx? > > Thanks. > Sean > > -- > View this message in context: > http://forum.world.st/Mocketry-tp3555258p3676822.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Dennis Schetinin

July 19, 2011

Re: [Pharo-project] Mocketry?

by Sean P. DeNigris

I read that Mocketry is compatible with the SUnit test runner. How would one use it like this? call #verify at the end of a TestCaseSubclass>>testXxx? Thanks. Sean -- View this message in context: http://forum.world.st/Mocketry-tp3555258p3676822.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 18, 2011