SUnit
Locked
1234
1234
 
|
Stéphane Ducasse <stephane.ducasse@...> writes:
> Niall Ross <nfr@...> > they published them on squeaksource but I do not know where Found them in http://squeaksource/SUnit 28 tests, I am ... underwhelmed. Guess copy pasting the test resource fixes from the slide will do the job. --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Julian Fitzell-2
Julian Fitzell <jfitzell@...> writes:
> > 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. Awesome. Looking forward to your post! Guess the best strategy is to go for a Pharo-only rewrite, and then added portability as the design stabilizes. --AA -- Follow me http://twitter.com/akuhn Follow me http://twitter.com/jexample Follow me http://twitter.com/codemap Follow me http://twitter.com/suite2010 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Adrian Kuhn
Not that I have finished any of the other projects that are of importance to me... but I am wondering how/where to get started with sound. I have no idea what capabilities already exist even though there is a long list of related classes. Can I record from a mic and get the list of notes? etc.
thanks in advance, Cam _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
A first fork is available
Gofer it squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load it has two new behaviors, TAssertable and TestToken. In the old design class `TestCase` had two purposes: once as context of a running test, and once as result of a test after having been run. The new design separates these two roles, which had both different state and different life time. No more nullifying of instance variables after a test has been run. Also the outcome of tests (ie whether passed or not) has been moved from test result to the tokens. Next up is to change test suites such that they contain tokens rather than test cases, and establish tokens as unique identifiers of test cases (such that we can compare aTestCase token with #==). Distribute source control ftw! --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
What is a TestToken?
Stef On Dec 22, 2009, at 6:27 PM, Adrian Kuhn wrote: > A first fork is available > > Gofer it > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load > > it has two new behaviors, TAssertable and TestToken. > > In the old design class `TestCase` had two purposes: once as context of a > running test, and once as result of a test after having been run. The new > design separates these two roles, which had both different state and different > life time. No more nullifying of instance variables after a test has been run. > Also the outcome of tests (ie whether passed or not) has been moved from test > result to the tokens. > > Next up is to change test suites such that they contain tokens rather than test > cases, and establish tokens as unique identifiers of test cases (such that we > can compare aTestCase token with #==). > > Distribute source control ftw! > > --AA > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Stéphane Ducasse <stephane.ducasse@...> writes:
> What is a TestToken? TestToken store the result of a single test case, whereas TestResult stores the result of an entire test suite. The life time of tokens may possible be persistent. While the life time of TestCase instances is strictly limited to the duration of one test run. --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Ok so why don't you use a better name
SingleTestResult because Token does not talk to me. On Dec 22, 2009, at 8:23 PM, Adrian Kuhn wrote: > Stéphane Ducasse <stephane.ducasse@...> writes: > >> What is a TestToken? > > TestToken store the result of a single test case, whereas TestResult stores the > result of an entire test suite. The life time of tokens may possible be > persistent. While the life time of TestCase instances is strictly limited to > the duration of one test run. > > --AA > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Adrian Kuhn
Adrian Kuhn wrote:
> A first fork is available > > Gofer it > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load Is it too late to call it SUnit2, SUnit3, whatever? When I see SUnit, I expect only the "standard" SUnit (i.e. TestCase, TestSuite, test resources, and various #assert: methods). Am I the only one that has a problem with calling this new direction "SUnit", without qualifying it with some version. I see a parallel with JUnit 3 vs 4 in the Java world. JUnit4 uses annotations to indicate test cases - no "test" prefix needed. When these test cases are run against JUnit3, nothing fails (and it appears to have passed) - but the tests have not been run at all, since without the "test" prefix, they're not recognized as test cases. Maybe nothing similar will happen with the new SUnit. What happens is that people start writing test cases assuming the newer version. Then at some point there's a conflict, and you either have to re-write your old or your new test cases. Maybe it's okay to be forced to update your old test cases, but it would be good know which version of the "SUnit API" is available or required. -- Yanni Chiu _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Julian Fitzell-2
Julian Fitzell wrote:
> > It would be really nice to have *one* SUnit that worked everywhere > with only minor platform-dependent pieces (like Seaside) where > necessary. This would be much more sustainable than the forked > situation we have currently, but that's a whole different battle. Yes. > 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. Some months ago Niall Ross took over maintainership of SUnit. IIRC he had the blessing of the previous maintainers, who hadn't been able to actually do much with it in recent years. At ESUG in Brest, Niall was actively working on SUnit and talking to folks from various Smalltalk implementations to try to get stuff into the next "official" release that would make everyone happy. So there is work going on to attempt to make the situation better. I'd think you'd want to at least discuss this with Niall and look at what he's done before starting over from scratch. If what's there doesn't meet Pharo's needs, starting from scratch might be appropriate. But if there can be "one true SUnit" for all Smalltalk, that seems like a better answer. Regards, -Martin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Tue, Dec 22, 2009 at 2:17 PM, Martin McClure <[hidden email]> wrote:
> But if > there can be "one true SUnit" for all Smalltalk, that seems like a > better answer. Agreed. Julian _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
VisualWorks has interesting framework Assessments http://blogten.blogspot.com/2009/07/what-is-assessments.html.
Maybe squeak/pharo port would be better then another new SUnit implementation _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On 21 déc. 2009, at 18:04, Stéphane Ducasse wrote:
This feature already exists in the TestRunner, unfortunately it is not well-known (as many features hidden in contextual menu) and not well integrated as you have to run tests through the test runner (I guess many people directly ran their test through the browser nowadays). So my point is: be careful about UI integration, but I guess that rethinking a bit the SUnit core to have the history allow us to remove the current hack. -- Simon _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Yanni Chiu
Yanni Chiu <yanni@...> writes:
> > Gofer it > > squeaksource: 'akuhn'; > > package: 'SUnit'; > > package: 'SUnitGUI'; > > load > > Is it too late to call it SUnit2, SUnit3, whatever? Too early in my opinion :) I follow the github style of forking, ie "fork early, fork often". The name of a fork is qualified by prefixing it with the name of the forker, so my fork is qualified "akuhn/SUnit". IMHO it is early enough to think about a new name when it is (ever?) merged back into Pharo. Phunit might be nice. @stef that might make a nice feature for new package system: to tell in an immediately visible way from which repo a package/class is coming. > What happens is that people start writing test cases assuming the newer > version. Then at some point there's a conflict, and you either have to > re-write your old or your new test cases. Maybe it's okay to be forced > to update your old test cases, but it would be good know which version > of the "SUnit API" is available or required. Good point, I share your concern. Maybe something like self assumeSUnitIsAkuhnFork might help. This will fail with DNU on all version except my fork. --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Stéphane Ducasse <stephane.ducasse@...> writes:
> Ok so why don't you use a better name > > SingleTestResult > > because Token does not talk to me. Consider all names tentative for the moment. Suggestion are indeed welcome. --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Martin McClure-2
Martin McClure <martin@...> writes:
> Some months ago Niall Ross took over maintainership of SUnit. IIRC he > had the blessing of the previous maintainers, who hadn't been able to > actually do much with it in recent years. At ESUG in Brest, Niall was > actively working on SUnit and talking to folks from various Smalltalk > implementations to try to get stuff into the next "official" release > that would make everyone happy. > > So there is work going on to attempt to make the situation better. I'd > think you'd want to at least discuss this with Niall and look at what > he's done before starting over from scratch. If what's there doesn't > meet Pharo's needs, starting from scratch might be appropriate. But if > there can be "one true SUnit" for all Smalltalk, that seems like a > better answer. Sure thing, I'll contact Niall. --AA -- Follow me http://twitter.com/akuhn Follow me http://twitter.com/codemap Follow me http://twitter.com/jexample Follow me http://twitter.com/suite2010 Follow me http://twitter.com/dyla2010 -- new! _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Denis Kudriashov
Denis Kudriashov <dionisiydk@...> writes:
> VisualWorks has interesting framework Assessments > http://blogten.blogspot.com/2009/07/what-is-assessments.html Cool, I'll look at that. Thanks --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Adrian Kuhn
On Dec 23, 2009, at 5:17 PM, Adrian Kuhn wrote: > Yanni Chiu <yanni@...> writes: > >>> Gofer it >>> squeaksource: 'akuhn'; >>> package: 'SUnit'; >>> package: 'SUnitGUI'; >>> load >> >> Is it too late to call it SUnit2, SUnit3, whatever? > > Too early in my opinion :) > > I follow the github style of forking, ie "fork early, fork often". The name of > a fork is qualified by prefixing it with the name of the forker, so my fork is > qualified "akuhn/SUnit". IMHO it is early enough to think about a new name > when it is (ever?) merged back into Pharo. Phunit might be nice. > > @stef that might make a nice feature for new package system: to tell in an > immediately visible way from which repo a package/class is coming. The problem is that you can have multiple repos. Now RPackage is disconnect orthogonal to MC and repo it is just a couple of classes to replace packageInfo. >> What happens is that people start writing test cases assuming the newer >> version. Then at some point there's a conflict, and you either have to >> re-write your old or your new test cases. Maybe it's okay to be forced >> to update your old test cases, but it would be good know which version >> of the "SUnit API" is available or required. > > Good point, I share your concern. Maybe something like > > self assumeSUnitIsAkuhnFork > > might help. This will fail with DNU on all version except my fork. > > --AA > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Adrian Kuhn
adrian it was presented at amsterdam.
I was good because it could deal with multiple exceptions and a lot more after my fear is that it was getting complex at the level of metaclass generation (if I remember correclty). >> VisualWorks has interesting framework Assessments >> http://blogten.blogspot.com/2009/07/what-is-assessments.html > > Cool, I'll look at that. > > Thanks > --AA > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: SUnit forked, gofer it
|
|
In reply to this post by Stéphane Ducasse
Can I add something to my dear santa list ??
Many times, I have tests that freeze the image. And I don't known what test was the "guilty". I always hack the runCase to show in Transcript the test selector. Maybe adding a configurable logging option (enable/disable) may help. Somehing like this: runCase Author ifUnknownAuthorUse: 'TestRunner' during: [ [ self log: 'Test to be performed: ', testSelector asSymbol asSring. self setUp. self performTest] ensure: [ self tearDown. self cleanUpInstanceVariables ] ] and then something like: log: aString self isLogEnable ifTrue: [Transcript show: aSring]. Or similar...but I like the idea of knowing which test make the image to freeze. Cheers, Mariano
On Wed, Dec 23, 2009 at 5:28 PM, Stéphane Ducasse <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Mariano Martinez Peck <marianopeck@...> writes:
> Can I add something to my dear santa list ??Many times, I have tests that > freeze the image. And I don't known what test was the "guilty". I always hack > the runCase to show in Transcript the test selector. Maybe adding a > configurable logging option (enable/disable) may help. Good point. I plan to add a TestListener that can be used to do this. --AA -- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |