- Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to execute code before and after a package is load?

by Alexandre Bergel

To obtain the after behavior, the classical way is to define an 'initialize' method on the class side of one your class. Cheers, Alexandre On 29 Dec 2009, at 04:09, Adrian Kuhn wrote: > It need to turn off system notifications for TestCase while gofer > updates > SUnit. One way I see would be to execute some code snippet before > and after > loading. However the Script button in Monticello seems to be broken. > I cannot > add scripts to the package. > > What can I do? > > So the current way to load akuhn SUnit is > > [SystemChangeNotifier uniqueInstance noMoreNotificationsFor: > TestCase. > Gofer it > displabePackageCache; > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load ] ensure: [ TestCase initialize ]. > > which is well ... quite ugly for a Gofer script. > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 29, 2009

[Pharo-project] How to execute code before and after a package is load?

by Adrian Kuhn

It need to turn off system notifications for TestCase while gofer updates SUnit. One way I see would be to execute some code snippet before and after loading. However the Script button in Monticello seems to be broken. I cannot add scripts to the package. What can I do? So the current way to load akuhn SUnit is [SystemChangeNotifier uniqueInstance noMoreNotificationsFor: TestCase. Gofer it displabePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load ] ensure: [ TestCase initialize ]. which is well ... quite ugly for a Gofer script. --AA

Dec. 29, 2009

Re: [Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Dale Henrichs

Dec. 29, 2009

Re: [Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > Thanks Adrian. All your improvments are really cool. The only thing that I am > concerned is that if I change all my tests to this style, Squeak people won't > be able to run the tests :( because that method won't be understood. True enough, that applies to any new feature. We cannot have evolution and full compatibility at the same time. I will try to ensure that old tests keep running. But regarding new features there is no guarantees (unless someone backports my changes). --AA

Dec. 29, 2009

Re: [Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Mariano Martinez Peck

On Tue, Dec 29, 2009 at 12:17 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Dec 28, 2009 at 11:19 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > >> Mariano Martinez Peck <marianopeck@...> writes: >> >> Assumptions are in the box! >> >> If you expect your test case to fail unless a given condition is met, you >> can >> now use assumptions to declare that. Gofer the latest akuhn/SUnit to get >> assumptions. >> >> For example, when your test case depends on the availability of a certain >> database you can write >> >> testBlob >> self assumeThat: Database default = DatabaseWithBlobs. >> ... >> >> if the assumption is true, the test case is run as a normal test case. If >> however the assumption is false, the test case is *not* run but still >> marked >> as passed. This is supposed to replace conditional #expectedFailures in >> the >> new SUnit. >> >> Typically, assumptions are put at the begin of a test case. However, you >> can >> put assumptions anywhere. The running tests case is aborted as soon as >> the >> first failing assumption is reached. >> >> PS regarding the naming: the message #assumeThat: has been preferred over >> a >> simple #assume: to make confusions with a simple #assert: less likely. >> >> > Thanks Adrian. All your improvments are really cool. The only thing that I > am concerned is that if I change all my tests to this style, Squeak people > won't be able to run the tests :( because that method won't be > understood. Anyway, I will si what can I do. > > Sorry I forgot to say that I just realized about that (because you asked me if it was ok and I said that yes). > Thank you very much for doing every day something better from SUnit!!! > > > --AA >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Dec. 29, 2009

Re: [Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 11:19 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Mariano Martinez Peck <marianopeck@...> writes: > > Assumptions are in the box! > > If you expect your test case to fail unless a given condition is met, you > can > now use assumptions to declare that. Gofer the latest akuhn/SUnit to get > assumptions. > > For example, when your test case depends on the availability of a certain > database you can write > > testBlob > self assumeThat: Database default = DatabaseWithBlobs. > ... > > if the assumption is true, the test case is run as a normal test case. If > however the assumption is false, the test case is *not* run but still > marked > as passed. This is supposed to replace conditional #expectedFailures in > the > new SUnit. > > Typically, assumptions are put at the begin of a test case. However, you > can > put assumptions anywhere. The running tests case is aborted as soon as the > first failing assumption is reached. > > PS regarding the naming: the message #assumeThat: has been preferred over a > simple #assume: to make confusions with a simple #assert: less likely. > > Thanks Adrian. All your improvments are really cool. The only thing that I am concerned is that if I change all my tests to this style, Squeak people won't be able to run the tests :( because that method won't be understood. Anyway, I will si what can I do. Thank you very much for doing every day something better from SUnit!!! --AA > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2009

Re: [Pharo-project] Tests of OmniBrowser

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 8:57 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > 2009/12/28 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Colin! I saw you were committing in the OmniBrowser tests. I am > > interested in loading these tests in Pharo (optionally). But I am not > sure > > which packages to include and their state. > > I spent quite some time to fix all Pharo related bugs in OB. > > Also I fixed all the tests that were broken in Pharo (only if O2 is not > loaded): > > 546 run, 546 passes, 0 failures, 0 errors > > This is really cool Lukas! > > Right now, in our Pharo images we are loading the following packages from > > http://source.wiresong.ca/ob > > AFAIK, the updated code from > http://source.lukas-renggli.ch/omnibrowser hasn't been merged into the > repository of Colin yet. I assume that will happen sometime soon. > > Colin: Right now we are building our official Pharo images using http://source.wiresong.ca/ob repository, not http://source.lukas-renggli.ch/omnibrowser Do you think that this can be merged ? > There are more related to the packages we are including? > > See OB-Umbrella, this loads all code in the right order. > > > should these test be all green? > > Definitely. OB has an excellent test suite. The only problem in the > past was that nobody that changed things run and updated these tests. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

[Pharo-project] Assumptions (was Re: akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: Assumptions are in the box! If you expect your test case to fail unless a given condition is met, you can now use assumptions to declare that. Gofer the latest akuhn/SUnit to get assumptions. For example, when your test case depends on the availability of a certain database you can write testBlob self assumeThat: Database default = DatabaseWithBlobs. ... if the assumption is true, the test case is run as a normal test case. If however the assumption is false, the test case is *not* run but still marked as passed. This is supposed to replace conditional #expectedFailures in the new SUnit. Typically, assumptions are put at the begin of a test case. However, you can put assumptions anywhere. The running tests case is aborted as soon as the first failing assumption is reached. PS regarding the naming: the message #assumeThat: has been preferred over a simple #assume: to make confusions with a simple #assert: less likely. --AA

Dec. 28, 2009

[Pharo-project] New class factory for tests (and other use cases)

by Adrian Kuhn

`ClassFactoryForTestCase` is a awesome tool when you need to create throw-away classes for tests. And the new akuhn/SUnit includes a DSL that makes creating anonymous classes even simpler! The new DSL is put in a new class to avoid compatibility issues. To create an anonymous class just do class := ClassFactory newClass. this creates a new subclass of Object. The creates classes is automatically reclaimed by garbage collection when no longer used. That is, tear down of class factory is not required anymore. The class is created without logging and not registered with the system. That is, `Object subclasses` does not include the created class. To create a subclass of a specific class do class := ClassFactory newSubclass: Point. To create a subclass with accessors do class := ClassFactory newSubclass: Point with: [ :f | f compileAccessorsFor: 'color' ]. If you want getters or setters only, use `#compileSetterFor:` or `#compilerGetterFor:`. If you want an instance variable without accessor, use `#declareInstVar:`. To create a subclass with methods do class := ClassFactory newSubclass: Point with: [ :f | f compile: 'answer ^ 42' ]. NB: please note that class factory compiles silently without logging. To create a method on the class side do class := ClassFactory newSubclass: Point with: [ :f | f forClass: [ :cf | cf compile: 'somePoint ^ self x: 2 y: 3' ]]. In fact, the class side factory `cf` supports the same protocol as the instance side factory. Please note that creating instance variables on the class side creates "class instances variables" and not "instance class variables". That is, they are local to the creates class but not to subclasses of the created class. Typically this should not be a limitation since you only create one class without further subclasses. Also, please note that the created classes and all instances created from that class are ment to be thrown away after their use. The created class is not registered with the system, and thus when you change the instance size of its superclass the created instances will not be updated. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load --AA

Dec. 28, 2009

Re: [Pharo-project] Tests of OmniBrowser

by Adrian Kuhn

Lukas Renggli <renggli@...> writes: > Definitely. OB has an excellent test suite. The only problem in the past was > that nobody that changed things run and updated these tests. Good point. When I have a fix for OB under pharo. What is the preferred process. So far I posted them on the bug tracker, is that okay? --AA

Dec. 28, 2009