December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SUnit

by StÃ©phane Ducasse

> - get the same API (I think that sharing code amongst smalltalk is a too >> large constraint but having the same API is important) > > Yes, legacy tests should keep running. > > On the other hand, what is an API in Smalltalk? We just got methods, and they > are *all* public. So when cleaning SUnit we have to draw a line. No doubt, > #assert: and friends are API, but what about eg #runCase? you cut some line. > >> - integrate key features of extensions so that SUNIT and SUNITExtended is >> cooler. > > Is "SUNITExtended" a project for Pharo? yes for example. >> - check what keith did on his Sunit extensions > > Where can I find those? Which keith, email? keith hodges > >> - have expected failures >> - have the possibility to know whether a test was red or green when it was >> saved and now when I run it, is it my fault or what is just before like that > > +1 ... no, +100 :) > >>> - add expectations matchers as used in behavior-driven testing >> Please not keep this separated or in another package. > > Users should be free to choose between assertions and expectations. Assertions > will stay. For me expectations are already implemented in SSpec and keith merged them in his SUnit extensions and nobody used them and after he was not happy. So keep the core small concentrate on what is the key aspect we do not want a bloated SUnit. So tests dependencies seem important while expectations someextra features. We do not want NGUnit where you can also do the washing. > >>> - break testcase into two classes, and to run the test and one to store the >>> result (no more #cleanUpInstanceVariables hack to avoid memory leaks) >> >> what would be the impact on existing subclasses? > > There should be none. > > Tools however might have to be changed, since a test result will contain test > descriptions rather than zombified test cases. > >> I suggest the following >> - clean and get a strong core >> - make sure that all the tests still run >> - get a set of extensions that people can load > > To me, the effort of cleaning up Sunit is worthwhile if we get a strong core > with support for test dependencies in the core. Phexample as an extension that > people can load is what we have now. What I imagine is a simple core with > clearly defined API, that allows other to write their own runners for their > test classes. For example, I would like to separate the role of running tests > and of containing tests (see my comment on class TestCase in the reply to > Julien.) This should allow better extensibility for everyone. ok > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 22, 2009

Re: [Pharo-project] SUnit

by StÃ©phane Ducasse

But this is why I was talking about API spec sharing vs code sharing. Stef On Dec 21, 2009, at 10:09 PM, Lukas Renggli wrote: >> BTW I do not know what is the status of the recent SUnit changes made by Nial >> I know that at ESUG they published a squeak version so it would be good to start there. > > I tries to merge that code, but more than half of the code-base is a > conflict. The SUnit framework in Squeak/Pharo has seen an uncountable > number of tiny changes that prevents a strait forward merge with the > official framework. > > 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. 22, 2009

Re: [Pharo-project] SUnit

by Julian Fitzell

On Mon, Dec 21, 2009 at 4:15 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Julian Fitzell <jfitzell@...> writes: > >> Well, the second may require working *with* SUnit maintainers on other >> platforms. :) > > Where can I find their names? Dunno... guess this is a start: http://sunit.sourceforge.net/people.htm >> I guess I don't know exactly what you define as >> "internal representation" but from Seaside's point of view it is >> absolutely essential that unit tests be runnable the same way on all >> platforms - it's the cornerstone of portability. > > Good point. Added as a requirement: current test should remain runnable, and > Â it should be possible to limit oneself to a set features that runs on all > Â platforms. > > One problem I see with legacy tests though is that TestCase serves currently > Â two purposes: a the superclass of all classes that contain tests, and as the > Â implementation of the internal logic that runs the tests. I don't how common > Â it is to override internal methods of test case in subclass (as eg #runCase > Â etc). In Seaside, eg, are you doing this? It seems we do not, though we do override #performTest in two cases. Both are cases where we need to wrap the execution in an exception handler. >> Although now I've said it, why not just start from scratch? There's >> not a lot of code there... implement something that works the way you >> want, build it using Grease/Slime so we can port it easily to >> everywhere else, and that's something Seaside could use (assuming it >> was compellingly better). And suddenly we'd have a test framework that >> *did* run everywhere with a common code base. > > Compelling, but can this be done without being a cross-platform expert? I > Â recall the pain of getting Fame to run in both VW and Squeak, eventually I > Â gave up. Cross-platform integration server, anyone? > > What is Grease/Slime? I don't know - we've become pseudo-experts for Seaside but it doesn't seem to be that tough in our case - just a matter of avoiding lots of things that aren't compatible. Grease is the light-weight compatibility layer we have ended up developing out of the Seaside project. I also used it to port Magritte and Pier to VA Smalltalk and Colin and I are now beginning to use it for MC2. Slime is a set of lint rules - currently some of them are Seaside-specific but others are essentially a counterpart to Grease - detecting things that you cannot do if you want your code to be portable. The hope is that others can leverage the experience we've developed and our porters' efforts getting Grease running on their platforms. I still need to finish a write-up on what Grease is and post it somewhere - on my todo list for the holidays. Julian

Dec. 22, 2009

Re: [Pharo-project] SUnit

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > - get the same API (I think that sharing code amongst smalltalk is a too > large constraint but having the same API is important) Yes, legacy tests should keep running. On the other hand, what is an API in Smalltalk? We just got methods, and they are *all* public. So when cleaning SUnit we have to draw a line. No doubt, #assert: and friends are API, but what about eg #runCase? > - integrate key features of extensions so that SUNIT and SUNITExtended is > cooler. Is "SUNITExtended" a project for Pharo? > - check what keith did on his Sunit extensions Where can I find those? Which keith, email? > - have expected failures > - have the possibility to know whether a test was red or green when it was > saved and now when I run it, is it my fault or what is just before like that +1 ... no, +100 :) > > - add expectations matchers as used in behavior-driven testing > Please not keep this separated or in another package. Users should be free to choose between assertions and expectations. Assertions will stay. > > - break testcase into two classes, and to run the test and one to store the > > result (no more #cleanUpInstanceVariables hack to avoid memory leaks) > > what would be the impact on existing subclasses? There should be none. Tools however might have to be changed, since a test result will contain test descriptions rather than zombified test cases. > I suggest the following > - clean and get a strong core > - make sure that all the tests still run > - get a set of extensions that people can load To me, the effort of cleaning up Sunit is worthwhile if we get a strong core with support for test dependencies in the core. Phexample as an extension that people can load is what we have now. What I imagine is a simple core with clearly defined API, that allows other to write their own runners for their test classes. For example, I would like to separate the role of running tests and of containing tests (see my comment on class TestCase in the reply to Julien.) This should allow better extensibility for everyone. --AA

Dec. 22, 2009

Re: [Pharo-project] SUnit

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > BTW I do not know what is the status of the recent SUnit changes made by > Nial. I know that at ESUG they published a squeak version so it would be > good to start there. Where can I find these changes? --AA

Dec. 22, 2009

Re: [Pharo-project] SUnit

by Adrian Kuhn

Julian Fitzell <jfitzell@...> writes: > Well, the second may require working *with* SUnit maintainers on other > platforms. :) Where can I find their names? > I guess I don't know exactly what you define as > "internal representation" but from Seaside's point of view it is > absolutely essential that unit tests be runnable the same way on all > platforms - it's the cornerstone of portability. Good point. Added as a requirement: current test should remain runnable, and it should be possible to limit oneself to a set features that runs on all platforms. One problem I see with legacy tests though is that TestCase serves currently two purposes: a the superclass of all classes that contain tests, and as the implementation of the internal logic that runs the tests. I don't how common it is to override internal methods of test case in subclass (as eg #runCase etc). In Seaside, eg, are you doing this? > Although now I've said it, why not just start from scratch? There's > not a lot of code there... implement something that works the way you > want, build it using Grease/Slime so we can port it easily to > everywhere else, and that's something Seaside could use (assuming it > was compellingly better). And suddenly we'd have a test framework that > *did* run everywhere with a common code base. Compelling, but can this be done without being a cross-platform expert? I recall the pain of getting Fame to run in both VW and Squeak, eventually I gave up. Cross-platform integration server, anyone? What is Grease/Slime? --AA

Dec. 22, 2009

Re: [Pharo-project] ISSUE #1647: TheTrunk-KernelTests-bs.121

by Mariano Martinez Peck

On Tue, Dec 22, 2009 at 12:00 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Pharo image: Pharo-core > Pharo core version: 11110 > Virtual machine used: Squeak 4.2.1beta1U > > This email takes the fixes sent in the email having the subjet: > - [squeak-dev] The Trunk: KernelTests-bs.121.mcz > - [squeak-dev] The Trunk: Kernel-bs.330.mcz > > After loading the .cs, we have for MethodPropertiesTest: > 11 run, 5 passes, 5 expected failures, 0 failures, 1 errors, 0 > unexpected passes > > The error left is for testAnalogousCode, not related to this fix. > > Thanks to Andreas Raab for the fix. > > Note to the reviewer: I put a .cs file on google code. Is that okay > with you? Or do you prefer a SLICE in the Inbox? > Would be nice to hear the voice of the "integrators" but I think most of the times they rather a slice so that it can be easily mergeable and they don't have to download the .cs, file in...etc. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 22, 2009

Re: [Pharo-project] SUnit

by Adrian Kuhn

laurent laffont <laurent.laffont@...> writes: > Hi, > > Isn't it similar to Thoughbot shoulda's nested contexts ? > http://github.com/thoughtbot/shoulda Yes it is, and no. Nested contexts from a tree, while test dependencies may possibly form a graph. At least when I last time looked at Shoulda and friends, the context were limited to a tree. A context can only be nested in at most one enclosing context. While with Phexample and friends, examples are nodes in a graph and may depend on as many other examples as required. cheers, AA

Dec. 21, 2009

[Pharo-project] Issue 1645: File browser holds onto volume when file browser is closed (Linux)

by Stan Shepherd

PharoCore1.0rc1 Latest update: #10500 VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Class browser used (if applicable): File browser Steps to reproduce: 1.Mount USB dive with .st file 2.In file browser, navigate to USB drive and filein the file 3.Close file browser 4.From Linux, attempt to unmount drive. receive message unable to unmount, an application is using the drive. 5. Reopen file browser, navigate to hard drive 6. USB drive can now be unmounted File browser should release the drive on closing -- View this message in context: http://n2.nabble.com/Issue-1645-File-browser-holds-onto-volume-when-file-br… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 21, 2009

[Pharo-project] ISSUE #1647: TheTrunk-KernelTests-bs.121

by Alexandre Bergel

Pharo image: Pharo-core Pharo core version: 11110 Virtual machine used: Squeak 4.2.1beta1U This email takes the fixes sent in the email having the subjet: - [squeak-dev] The Trunk: KernelTests-bs.121.mcz - [squeak-dev] The Trunk: Kernel-bs.330.mcz After loading the .cs, we have for MethodPropertiesTest: 11 run, 5 passes, 5 expected failures, 0 failures, 1 errors, 0 unexpected passes The error left is for testAnalogousCode, not related to this fix. Thanks to Andreas Raab for the fix. Note to the reviewer: I put a .cs file on google code. Is that okay with you? Or do you prefer a SLICE in the Inbox? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 21, 2009