[Pharo-project] SUnit
Niko and me are thinking about doing some work on SUnit. Background is that we are working on Phexample, which extends SUnit with test that expand on one another [1]. We got test dependencies working with the current SUnit, but had to do some quick ugly hacks. So we thought about cleaning the internals SUnit up, and then include test dependencies in the core. Things we would possible change (we will certainly identify more as we clean up SUnit...) - store test resources in a dynamic variable rather than a static one - refactor the assert: protocol to a trait, such that they can be used in setup and teardown of test resources as well (actually I already did that, you can find a version on my squeaksource account) - apply the fixes to test resources in Niall's slide deck that Lukas showed us - add expectations matchers as used in behavior-driven testing - break testcase into two classes, and to run the test and one to store the result (no more #cleanUpInstanceVariables hack to avoid memory leaks) - add test dependencies to test results, such that one test can extend on the return value of another test - fix expected failures such that they are a first-class result (no more #shouldPass with O(n^2) or worse behavior) So you see, the idea is twofold: first to clean up what is there, and second to add test dependencies as a new feature. For those that dont know test dependencies. They had first been proposed by Markus Gälli based on an analysis of all Squeak tests years ago. He found that most tests cover a superset of another test's coverage set. A prototype in Java as been implemented later by Lea Hänsenberger and me. We published a case study at XP 2008, which lead to PHP folks to include test dependencies in the latest PHPUnit. The idea of explicit test dependencies is to shift the burden of isolating test cases from the developers to the framework. You avoid duplicate test code and you get less red test cases per failure. Please refer to Niko's blog post for more details [2]. We got some more ideas (such as API baseline testing, search in test results, etc...) but they will not likely make it into a first clean up. One thing we do not know is how many folks are out there that depend on internal representation of SUnit. I talked to some folks and identified two requirements, first that legacy tests should keep running and second that contributions to other sunit forks should keep being mergeable. The first seems feasible, the second sounds like it boils down to not cleaning anything :) What do you think? cheers, AA [1]: http://www.squeaksource.com/phexample.html [2]: http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-exp...
Hi adrian I like the idea of cleaning. Now here is what I would like - get the same API (I think that sharing code amongst smalltalk is a too large constraint but having the same API is important) - integrate key features of extensions so that SUNIT and SUNITExtended is cooler.
Niko and me are thinking about doing some work on SUnit.
Background is that we are working on Phexample, which extends SUnit with test that expand on one another [1]. We got test dependencies working with the current SUnit, but had to do some quick ugly hacks. So we thought about cleaning the internals SUnit up, and then include test dependencies in the core.
Things we would possible change (we will certainly identify more as we clean up SUnit...)
- store test resources in a dynamic variable rather than a static one
for this one I would not rely on dynamic variables. Keep it for later. And you will have to really argue. Static scoping is nice.
- refactor the assert: protocol to a trait, such that they can be used in setup and teardown of test resources as well (actually I already did that, you can find a version on my squeaksource account)
:) Easy I'm biaised :)
- apply the fixes to test resources in Niall's slide deck that Lukas showed us
Pleaseeeeeeeee. I would really like to also - check what keith did on his Sunit extensions - 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
- add expectations matchers as used in behavior-driven testing Please not keep this separated or in another package. I do not like this "bla be something" kind of violation of law of demeter
- 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?
- add test dependencies to test results, such that one test can extend on the return value of another test I originally did not like the idea but I can be convinced easily :) I think that if it can help other without getting in our way then this is cool.
- fix expected failures such that they are a first-class result (no more #shouldPass with O(n^2) or worse behavior)
So you see, the idea is twofold: first to clean up what is there, and second to add test dependencies as a new feature. For those that dont know test dependencies. They had first been proposed by Markus Gälli based on an analysis of all Squeak tests years ago. He found that most tests cover a superset of another test's coverage set. A prototype in Java as been implemented later by Lea Hänsenberger and me. We published a case study at XP 2008, which lead to PHP folks to include test dependencies in the latest PHPUnit. The idea of explicit test dependencies is to shift the burden of isolating test cases from the developers to the framework. You avoid duplicate test code and you get less red test cases per failure. Please refer to Niko's blog post for more details [2].
We got some more ideas (such as API baseline testing, search in test results, etc...) but they will not likely make it into a first clean up.
Yes clean up first!
One thing we do not know is how many folks are out there that depend on internal representation of SUnit. I talked to some folks and identified two requirements, first that legacy tests should keep running and second that contributions to other sunit forks should keep being mergeable. The first seems feasible, the second sounds like it boils down to not cleaning anything :)
Merging does not mean that this is done automatically. I think that having a good testing framework is important. Now good does not mean that it has a lot of not that useful features. 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
What do you think?
I'm interested :) but people will have to discuss your proposal :) Stef
cheers, AA
[1]: http://www.squeaksource.com/phexample.html [2]: http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-exp...
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
- 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
I know a lot of SUnit tests override #runCase. Basically all tests that need to setup a dynamic environment (e.g. to simulate a session). Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli <renggli@...> writes:
I know a lot of SUnit tests override #runCase. Basically all tests that need to setup a dynamic environment (e.g. to simulate a session).
For cases such as `Whatever while: [ super runCase ]` that cannot be split into setUp and tearDown method. Good point, added to requirements list. --AA
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
Cameron Sanders <camsanders01@...> writes:
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.
Guess your message ended up in the wrong thread. Try repost as top level message, ie create a fresh email and manually enter the address of the mailing list (if you reply to any mail from the list, your mail is included in the running thread and only few folks will notice it). --AA
On Tue, Dec 22, 2009 at 1:37 AM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
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?
I think it is this: http://www.squeaksource.com/Testing http://wiki.squeak.org/squeak/SUnit%20for%203.10 And there is also some extensions made by Hernán Wilkinson. Maybe they are of help. They are here: http://www.squeaksource.com/SUnitExtensions Cheers Mariano
- 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck <marianopeck@...> writes:
I think it is this:Â Â http://www.squeaksource.com/Testing
53 tests, hmm...
28 tests, I am ... underwhelmed.
And there is also some extensions made by Hernán Wilkinson.
Looks they are already in Pharo, some under other names. Thanks. --AA
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
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 Pharo-project@lists.gforge.inria.fr 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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr
wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
On Wed, Dec 23, 2009 at 7:20 PM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
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.
You have already thought in everything ;) Excellent then!!! Thank you :) Mariano
--AA
-- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian I know that in GNUSMalltalk paolo long time ago added logging facilities (I never looked at it so may be this is just the description: but joseph once talked about that when he presented toothpick at Bern). Stef On Dec 23, 2009, at 7:20 PM, Adrian Kuhn wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Dec 23, 2009 at 7:36 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Adrian
I know that in GNUSMalltalk paolo long time ago added logging facilities (I never looked at it so may be this is just the description: but joseph once talked about that when he presented toothpick at Bern).
In addition I also remember Kieth work for Logging which was a frontend for different loggers such us SimpleLog. Links: http://wiki.squeak.org/squeak/3706 http://wiki.squeak.org/squeak/5890 Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ? how? Cheers, Mariano
Stef
On Dec 23, 2009, at 7:20 PM, Adrian Kuhn wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano Martinez Peck <marianopeck@...> writes:
Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ?
Fixed in my image. If you file a bug report, I'll attach the fix :) --AA
On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
Mariano Martinez Peck <marianopeck@...> writes:
Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ?
Fixed in my image.
If you file a bug report, I'll attach the fix :)
Excellent!!!! http://code.google.com/p/pharo/issues/detail?id=1665 Let me say that I really like all the little improvements that are being done. Cheers, Mariano
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In the current OB browser(s), if you press Command+T on a selected test method runs only that test. Cheers, Doru On 23 Dec 2009, at 21:47, Mariano Martinez Peck wrote:
On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote: Mariano Martinez Peck <marianopeck@...> writes:
Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ?
Fixed in my image.
If you file a bug report, I'll attach the fix :)
Excellent!!!!
http://code.google.com/p/pharo/issues/detail?id=1665
Let me say that I really like all the little improvements that are being done.
Cheers,
Mariano
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Be rather willing to give than demanding to get."
On Thu, Dec 24, 2009 at 12:22 AM, Tudor Girba <tudor.girba@gmail.com> wrote:
In the current OB browser(s), if you press Command+T on a selected test method runs only that test.
Are you sure ? If it press cmd + t over a test method, it is not executed only that method but also all the rest test methods of that class. I am trying 10496 dev with OBSystemBrowserAdaptor. I have checked again just in case but still have that behaviour. Cheers Mariano
Cheers, Doru
On 23 Dec 2009, at 21:47, Mariano Martinez Peck wrote:
On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote: Mariano Martinez Peck <marianopeck@...> writes:
Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ?
Fixed in my image.
If you file a bug report, I'll attach the fix :)
Excellent!!!!
http://code.google.com/p/pharo/issues/detail?id=1665
Let me say that I really like all the little improvements that are being done.
Cheers,
Mariano
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It should work if your mouse is over the methods pane. Cheers, Doru On 24 Dec 2009, at 00:41, Mariano Martinez Peck wrote:
On Thu, Dec 24, 2009 at 12:22 AM, Tudor Girba <tudor.girba@gmail.com> wrote: In the current OB browser(s), if you press Command+T on a selected test method runs only that test.
Are you sure ? If it press cmd + t over a test method, it is not executed only that method but also all the rest test methods of that class. I am trying 10496 dev with OBSystemBrowserAdaptor. I have checked again just in case but still have that behaviour.
Cheers
Mariano
Cheers, Doru
On 23 Dec 2009, at 21:47, Mariano Martinez Peck wrote:
On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote: Mariano Martinez Peck <marianopeck@...> writes:
Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ?
Fixed in my image.
If you file a bug report, I'll attach the fix :)
Excellent!!!!
http://code.google.com/p/pharo/issues/detail?id=1665
Let me say that I really like all the little improvements that are being done.
Cheers,
Mariano
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Reasonable is what we are accustomed with."
Is this by accident or was by design? It seems too convoluted this mouse pointer modality plus some specific key combination. . . Em 23/12/2009 22:23, Tudor Girba < tudor.girba@gmail.com > escreveu: It should work if your mouse is over the methods pane. Cheers, Doru On 24 Dec 2009, at 00:41, Mariano Martinez Peck wrote:
On Thu, Dec 24, 2009 at 12:22 AM, Tudor Girba wrote: In the current OB browser(s), if you press Command+T on a selected test method runs only that test.
Are you sure ? If it press cmd + t over a test method, it is not executed only that method but also all the rest test methods of that class. I am trying 10496 dev with OBSystemBrowserAdaptor. I have checked again just in case but still have that behaviour.
Cheers
Mariano
Cheers, Doru
On 23 Dec 2009, at 21:47, Mariano Martinez Peck wrote:
On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn wrote: Mariano Martinez Peck writes:
Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ?
Fixed in my image.
If you file a bug report, I'll attach the fix :)
Excellent!!!!
http://code.google.com/p/pharo/issues/detail?id=1665
Let me say that I really like all the little improvements that are being done.
Cheers,
Mariano
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Reasonable is what we are accustomed with." _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I actually do not know. I just know it is like that and that I would prefer to have a more straightforward action mapping :). Cheers, Doru On 24 Dec 2009, at 01:29, csrabak@bol.com.br wrote:
Is this by accident or was by design? It seems too convoluted this mouse pointer modality plus some specific key combination. . .
Em 23/12/2009 22:23, Tudor Girba < tudor.girba@gmail.com > escreveu:
It should work if your mouse is over the methods pane.
Cheers, Doru
On 24 Dec 2009, at 00:41, Mariano Martinez Peck wrote:
On Thu, Dec 24, 2009 at 12:22 AM, Tudor Girba wrote: In the current OB browser(s), if you press Command+T on a selected test method runs only that test.
Are you sure ? If it press cmd + t over a test method, it is not executed only that method but also all the rest test methods of that class. I am trying 10496 dev with OBSystemBrowserAdaptor. I have checked again just in case but still have that behaviour.
Cheers
Mariano
Cheers, Doru
On 23 Dec 2009, at 21:47, Mariano Martinez Peck wrote:
On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn wrote: Mariano Martinez Peck writes:
Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ?
Fixed in my image.
If you file a bug report, I'll attach the fix :)
Excellent!!!!
http://code.google.com/p/pharo/issues/detail?id=1665
Let me say that I really like all the little improvements that are being done.
Cheers,
Mariano
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Beauty is where we see it."
Tudor Girba <tudor.girba@...> writes:
It should work if your mouse is over the methods pane.
Not true in OB. -- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010
Indeed, it aways runs all tests of a class. Should that be changed? I found it more useful to run them all, instead of just one. Lukas 2009/12/24 Adrian Kuhn <akuhn@iam.unibe.ch>:
Tudor Girba <tudor.girba@...> writes:
It should work if your mouse is over the methods pane.
Not true in OB.
-- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli <renggli@...> writes:
Indeed, it always runs all tests of a class. Should that be changed? I found it more useful to run them all, instead of just one.
Fixed it in my image (and attached on google). Its awesome when you work on one test in particular.It is somehow annoying when you browse a package ... click click click ... dive into one method and want to run the whole test case. But one might get used to it quickly. Maybe different action for Cmd+T in the source editor and the method list? (or is that too confusing?) --AA PS: also broken was that when you ran one method the history of all other methods was lost. Fixed in akuhn/SUnit now.
Normally it works to click on the class or package to run all the test of the packages now may be the binding does not do it but pressing on the icon was working like that On Dec 24, 2009, at 10:16 AM, Adrian Kuhn wrote:
Lukas Renggli <renggli@...> writes:
Indeed, it always runs all tests of a class. Should that be changed? I found it more useful to run them all, instead of just one.
Fixed it in my image (and attached on google).
Its awesome when you work on one test in particular.It is somehow annoying when you browse a package ... click click click ... dive into one method and want to run the whole test case. But one might get used to it quickly.
Maybe different action for Cmd+T in the source editor and the method list? (or is that too confusing?)
--AA
PS: also broken was that when you ran one method the history of all other methods was lost. Fixed in akuhn/SUnit now.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Dec 24, 2009 at 9:52 AM, Lukas Renggli <renggli@gmail.com> wrote:
Indeed, it aways runs all tests of a class. Should that be changed? I
Yes!!!! If you have selected a particular method, the idea is to run THAT method, not all. Why you need to select then ? If you want all methods go to the class or even to the tests runner.
found it more useful to run them all, instead of just one.
Lukas
2009/12/24 Adrian Kuhn <akuhn@iam.unibe.ch>:
Tudor Girba <tudor.girba@...> writes:
It should work if your mouse is over the methods pane.
Not true in OB.
-- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Changed in Name: OB-SUnitIntegration-lr.16 Author: lr Time: 24 December 2009, 10:54:56 am UUID: 661b0ef3-03df-4193-84ed-e482c9baaec6 Ancestors: OB-SUnitIntegration-AdrianKuhn.15 - run tests depending on selection 2009/12/24 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Dec 24, 2009 at 9:52 AM, Lukas Renggli <renggli@gmail.com> wrote:
Indeed, it aways runs all tests of a class. Should that be changed? I
Yes!!!!  If you have selected a particular method, the idea is to run THAT method, not all. Why you need to select then ? If you want all methods go to the class or even to the tests runner.
found it more useful to run them all, instead of just one.
Lukas
2009/12/24 Adrian Kuhn <akuhn@iam.unibe.ch>:
Tudor Girba <tudor.girba@...> writes:
It should work if your mouse is over the methods pane.
Not true in OB.
-- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
hahahah did I convinced you ? Thank you very much. This was my little christmas gift. I put the issue as closed. Cheers Mariano On Thu, Dec 24, 2009 at 10:56 AM, Lukas Renggli <renggli@gmail.com> wrote:
Changed in
Name: OB-SUnitIntegration-lr.16 Author: lr Time: 24 December 2009, 10:54:56 am UUID: 661b0ef3-03df-4193-84ed-e482c9baaec6 Ancestors: OB-SUnitIntegration-AdrianKuhn.15
- run tests depending on selection
2009/12/24 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Dec 24, 2009 at 9:52 AM, Lukas Renggli <renggli@gmail.com>
wrote:
Indeed, it aways runs all tests of a class. Should that be changed? I
Yes!!!! If you have selected a particular method, the idea is to run THAT method, not all. Why you need to select then ? If you want all methods go to the class or even to the tests runner.
found it more useful to run them all, instead of just one.
Lukas
2009/12/24 Adrian Kuhn <akuhn@iam.unibe.ch>:
Tudor Girba <tudor.girba@...> writes:
It should work if your mouse is over the methods pane.
Not true in OB.
-- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Dec 24, 2009 at 10:56 AM, Lukas Renggli <renggli@gmail.com> wrote:
Changed in
Name: OB-SUnitIntegration-lr.16 Author: lr Time: 24 December 2009, 10:54:56 am UUID: 661b0ef3-03df-4193-84ed-e482c9baaec6 Ancestors: OB-SUnitIntegration-AdrianKuhn.15
- run tests depending on selection
Are you sure you commited ? In http://source.wiresong.ca/ob the last version I see is OB-SUnitIntegration-AdrianKuhn.15 But maybe is a problem in my image or proxy caching something. Cheers and happy christmas. mariano
2009/12/24 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Dec 24, 2009 at 9:52 AM, Lukas Renggli <renggli@gmail.com>
wrote:
Indeed, it aways runs all tests of a class. Should that be changed? I
Yes!!!! If you have selected a particular method, the idea is to run THAT method, not all. Why you need to select then ? If you want all methods go to the class or even to the tests runner.
found it more useful to run them all, instead of just one.
Lukas
2009/12/24 Adrian Kuhn <akuhn@iam.unibe.ch>:
Tudor Girba <tudor.girba@...> writes:
It should work if your mouse is over the methods pane.
Not true in OB.
-- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I maintain my own "stable" fork of OB at http://source.lukas-renggli.ch/omnibrowser. Colin merges the code from time-to-time. I found that the official code was often broken or in-stable, because too many people changed things ... Lukas 2009/12/25 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Dec 24, 2009 at 10:56 AM, Lukas Renggli <renggli@gmail.com> wrote:
Changed in
Name: OB-SUnitIntegration-lr.16 Author: lr Time: 24 December 2009, 10:54:56 am UUID: 661b0ef3-03df-4193-84ed-e482c9baaec6 Ancestors: OB-SUnitIntegration-AdrianKuhn.15
- run tests depending on selection
Are you sure you commited ? In http://source.wiresong.ca/ob the last version I see is  OB-SUnitIntegration-AdrianKuhn.15 But maybe is a problem in my image or proxy caching something.
Cheers and happy christmas.
mariano
2009/12/24 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Dec 24, 2009 at 9:52 AM, Lukas Renggli <renggli@gmail.com> wrote:
Indeed, it aways runs all tests of a class. Should that be changed? I
Yes!!!!  If you have selected a particular method, the idea is to run THAT method, not all. Why you need to select then ? If you want all methods go to the class or even to the tests runner.
found it more useful to run them all, instead of just one.
Lukas
2009/12/24 Adrian Kuhn <akuhn@iam.unibe.ch>:
Tudor Girba <tudor.girba@...> writes:
It should work if your mouse is over the methods pane.
Not true in OB.
-- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
On Fri, Dec 25, 2009 at 1:54 PM, Lukas Renggli <renggli@gmail.com> wrote:
I maintain my own "stable" fork of OB at http://source.lukas-renggli.ch/omnibrowser. Colin merges the code from time-to-time. I found that the official code was often broken or in-stable, because too many people changed things ...
Ok... I didn't know about that. The problem is that in the pharo scripts we are using to generate the dev image we install OB from here: http://source.wiresong.ca/ob :( Can I commit it there? what can be the problem ? Thanks Mariano Lukas
2009/12/25 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Dec 24, 2009 at 10:56 AM, Lukas Renggli <renggli@gmail.com>
wrote:
Changed in
Name: OB-SUnitIntegration-lr.16 Author: lr Time: 24 December 2009, 10:54:56 am UUID: 661b0ef3-03df-4193-84ed-e482c9baaec6 Ancestors: OB-SUnitIntegration-AdrianKuhn.15
- run tests depending on selection
Are you sure you commited ? In http://source.wiresong.ca/ob the last version I see is OB-SUnitIntegration-AdrianKuhn.15 But maybe is a problem in my image or proxy caching something.
Cheers and happy christmas.
mariano
2009/12/24 Mariano Martinez Peck <marianopeck@gmail.com>:
On Thu, Dec 24, 2009 at 9:52 AM, Lukas Renggli <renggli@gmail.com> wrote:
Indeed, it aways runs all tests of a class. Should that be changed? I
Yes!!!! If you have selected a particular method, the idea is to run THAT method, not all. Why you need to select then ? If you want all methods go to the class or even to the tests runner.
found it more useful to run them all, instead of just one.
Lukas
2009/12/24 Adrian Kuhn <akuhn@iam.unibe.ch>:
Tudor Girba <tudor.girba@...> writes:
It should work if your mouse is over the methods pane.
Not true in OB.
-- 4th Workshop on Dynamic Languages and Applications Submit papers by March 31, 2010. http://bit.ly/dyla2010
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Can I commit it there? what can be the problem ?
I copied it there. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Hi, may be you can take a look at TDDFacilities on squeaksource, you can press Ctr+t in the code panel to run the test. There's other facilities that speed up TDD, I like it. See http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/010033.html Cheers, Laurent Laffont On Thu, Dec 24, 2009 at 12:22 AM, Tudor Girba <tudor.girba@gmail.com> wrote:
In the current OB browser(s), if you press Command+T on a selected test method runs only that test.
Cheers, Doru
On 23 Dec 2009, at 21:47, Mariano Martinez Peck wrote:
On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote: Mariano Martinez Peck <marianopeck@...> writes:
Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ?
Fixed in my image.
If you file a bug report, I'll attach the fix :)
Excellent!!!!
http://code.google.com/p/pharo/issues/detail?id=1665
Let me say that I really like all the little improvements that are being done.
Cheers,
Mariano
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
5. It does not ask for unknown selectors or unused variables when a method is saved is integrated already may be in 1.1 only I do not remember On Dec 24, 2009, at 8:32 AM, laurent laffont wrote:
Hi,
may be you can take a look at TDDFacilities on squeaksource, you can press Ctr+t in the code panel to run the test.
There's other facilities that speed up TDD, I like it. See http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/010033.html
Cheers,
Laurent Laffont
On Thu, Dec 24, 2009 at 12:22 AM, Tudor Girba <tudor.girba@gmail.com> wrote: In the current OB browser(s), if you press Command+T on a selected test method runs only that test.
Cheers, Doru
On 23 Dec 2009, at 21:47, Mariano Martinez Peck wrote:
On Wed, Dec 23, 2009 at 9:41 PM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote: Mariano Martinez Peck <marianopeck@...> writes:
Sorry for go a bit offtopic, but is it possible to run only ONE test from the browser??? I would like to right click on a test method and be execute. Just like the "run tests" option but only for THAT test and not all the tests of that class. Is that possible ?
Fixed in my image.
If you file a bug report, I'll attach the fix :)
Excellent!!!!
http://code.google.com/p/pharo/issues/detail?id=1665
Let me say that I really like all the little improvements that are being done.
Cheers,
Mariano
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 21 déc. 2009, at 18:04, Stéphane Ducasse wrote:
Hi adrian
Pleaseeeeeeeee. I would really like to also - check what keith did on his Sunit extensions - 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
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
On Mon, Dec 21, 2009 at 8:06 AM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
One thing we do not know is how many folks are out there that depend on  internal representation of SUnit. I talked to some folks and identified two  requirements, first that legacy tests should keep running and second that  contributions to other sunit forks should keep being mergeable. The first  seems feasible, the second sounds like it boils down to not cleaning  anything :)
Well, the second may require working *with* SUnit maintainers on other platforms. :) 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. The fact that we can't write lint rules that work on all platforms is already sad enough. So if you're going to do anything that breaks compatibility between platforms, please rename it and make sure both are loadable in the same system (and we, at least, won't be able to use it). 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. 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. my 2c, Julian
Thanks julian. I think that this is nice way to look at it. Defining another one would be good - the only important point is that we could load it and it can transparently replace SUnit. 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. Stef
On Mon, Dec 21, 2009 at 8:06 AM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
One thing we do not know is how many folks are out there that depend on internal representation of SUnit. I talked to some folks and identified two requirements, first that legacy tests should keep running and second that contributions to other sunit forks should keep being mergeable. The first seems feasible, the second sounds like it boils down to not cleaning anything :)
Well, the second may require working *with* SUnit maintainers on other platforms. :) 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. The fact that we can't write lint rules that work on all platforms is already sad enough.
So if you're going to do anything that breaks compatibility between platforms, please rename it and make sure both are loadable in the same system (and we, at least, won't be able to use it).
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. 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.
my 2c,
Julian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Dec 21, 2009 at 9:36 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Thanks julian. I think that this is nice way to look at it.
Defining another one would be good - the only important point is that we could load it and it can transparently replace SUnit.
Yes, it would be nice if it still supported the same basic protocol (#assert:, #deny:, etc) so you could simply change the superclass of your test cases and things would (at least more or less) work. Julian
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Dec 22, 2009, at 1:16 AM, Adrian Kuhn wrote:
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?
Niall Ross <nfr@bigwig.net> they published them on squeaksource but I do not know where
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
On Mon, Dec 21, 2009 at 4:15 PM, Adrian Kuhn <akuhn@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
On Dec 22, 2009, at 4:34 AM, Julian Fitzell wrote:
On Mon, Dec 21, 2009 at 4:15 PM, Adrian Kuhn <akuhn@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 would not go down this road :) Just define a new one that is compatible.
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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!
Hi, Isn't it similar to Thoughbot shoulda's nested contexts ? http://github.com/thoughtbot/shoulda Laurent On Mon, Dec 21, 2009 at 5:06 PM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
Niko and me are thinking about doing some work on SUnit.
Background is that we are working on Phexample, which extends SUnit with test that expand on one another [1]. We got test dependencies working with the current SUnit, but had to do some quick ugly hacks. So we thought about cleaning the internals SUnit up, and then include test dependencies in the core.
Things we would possible change (we will certainly identify more as we clean up SUnit...)
- store test resources in a dynamic variable rather than a static one - refactor the assert: protocol to a trait, such that they can be used in setup and teardown of test resources as well (actually I already did that, you can find a version on my squeaksource account) - apply the fixes to test resources in Niall's slide deck that Lukas showed us - add expectations matchers as used in behavior-driven testing - break testcase into two classes, and to run the test and one to store the result (no more #cleanUpInstanceVariables hack to avoid memory leaks) - add test dependencies to test results, such that one test can extend on the return value of another test - fix expected failures such that they are a first-class result (no more #shouldPass with O(n^2) or worse behavior)
So you see, the idea is twofold: first to clean up what is there, and second to add test dependencies as a new feature. For those that dont know test dependencies. They had first been proposed by Markus Gälli based on an analysis of all Squeak tests years ago. He found that most tests cover a superset of another test's coverage set. A prototype in Java as been implemented later by Lea Hänsenberger and me. We published a case study at XP 2008, which lead to PHP folks to include test dependencies in the latest PHPUnit. The idea of explicit test dependencies is to shift the burden of isolating test cases from the developers to the framework. You avoid duplicate test code and you get less red test cases per failure. Please refer to Niko's blog post for more details [2].
We got some more ideas (such as API baseline testing, search in test results, etc...) but they will not likely make it into a first clean up.
One thing we do not know is how many folks are out there that depend on internal representation of SUnit. I talked to some folks and identified two requirements, first that legacy tests should keep running and second that contributions to other sunit forks should keep being mergeable. The first seems feasible, the second sounds like it boils down to not cleaning anything :)
What do you think?
cheers, AA
[1]: http://www.squeaksource.com/phexample.html [2]: http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-exp...
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
Adrian Kuhn wrote:
We got some more ideas (... search in test results)
Is there a way to see which tests invoked a given method? Sometimes you're trying to understand a method, to see if it does what you're trying to achieve. In such cases, it would be really handy to see which tests used a given method during a system-wide test, and then invoke one of those to give you a handle on the method. Does such a thing already exist? ...Stan
Niko and me are thinking about doing some work on SUnit.
Background is that we are working on Phexample, which extends SUnit with test that expand on one another [1]. We got test dependencies working with the current SUnit, but had to do some quick ugly hacks. So we thought about cleaning the internals SUnit up, and then include test dependencies in the core.
Things we would possible change (we will certainly identify more as we clean up SUnit...)
- store test resources in a dynamic variable rather than a static one - refactor the assert: protocol to a trait, such that they can be used in setup and teardown of test resources as well (actually I already did that, you can find a version on my squeaksource account) - apply the fixes to test resources in Niall's slide deck that Lukas showed us - add expectations matchers as used in behavior-driven testing - break testcase into two classes, and to run the test and one to store the result (no more #cleanUpInstanceVariables hack to avoid memory leaks) - add test dependencies to test results, such that one test can extend on the return value of another test - fix expected failures such that they are a first-class result (no more #shouldPass with O(n^2) or worse behavior)
So you see, the idea is twofold: first to clean up what is there, and second to add test dependencies as a new feature. For those that dont know test dependencies. They had first been proposed by Markus Gälli based on an analysis of all Squeak tests years ago. He found that most tests cover a superset of another test's coverage set. A prototype in Java as been implemented later by Lea Hänsenberger and me. We published a case study at XP 2008, which lead to PHP folks to include test dependencies in the latest PHPUnit. The idea of explicit test dependencies is to shift the burden of isolating test cases from the developers to the framework. You avoid duplicate test code and you get less red test cases per failure. Please refer to Niko's blog post for more details [2].
We got some more ideas (such as API baseline testing, search in test results, etc...) but they will not likely make it into a first clean up.
One thing we do not know is how many folks are out there that depend on internal representation of SUnit. I talked to some folks and identified two requirements, first that legacy tests should keep running and second that contributions to other sunit forks should keep being mergeable. The first seems feasible, the second sounds like it boils down to not cleaning anything :)
What do you think?
cheers, AA
[1]: http://www.squeaksource.com/phexample.html [2]: http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-exp...
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- View this message in context: http://n4.nabble.com/SUnit-tp1297972p1752629.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Given a set of tests you need to know which ones cover that method? is that what you want? We have a class to do that in MutationTesting package ( http://code.google.com/p/mutalk/) The class is called CoverageAnalysis. It has some tests to see how it works but you can ask me if you need help. On Tue, Apr 6, 2010 at 7:03 AM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Adrian Kuhn wrote:
We got some more ideas (... search in test results)
Is there a way to see which tests invoked a given method? Sometimes you're trying to understand a method, to see if it does what you're trying to achieve. In such cases, it would be really handy to see which tests used a given method during a system-wide test, and then invoke one of those to give you a handle on the method. Does such a thing already exist?
...Stan
Niko and me are thinking about doing some work on SUnit.
Background is that we are working on Phexample, which extends SUnit with test that expand on one another [1]. We got test dependencies working with the current SUnit, but had to do some quick ugly hacks. So we thought about cleaning the internals SUnit up, and then include test dependencies in the core.
Things we would possible change (we will certainly identify more as we clean up SUnit...)
- store test resources in a dynamic variable rather than a static one - refactor the assert: protocol to a trait, such that they can be used in setup and teardown of test resources as well (actually I already did that, you can find a version on my squeaksource account) - apply the fixes to test resources in Niall's slide deck that Lukas showed us - add expectations matchers as used in behavior-driven testing - break testcase into two classes, and to run the test and one to store the result (no more #cleanUpInstanceVariables hack to avoid memory leaks) - add test dependencies to test results, such that one test can extend on the return value of another test - fix expected failures such that they are a first-class result (no more #shouldPass with O(n^2) or worse behavior)
So you see, the idea is twofold: first to clean up what is there, and second to add test dependencies as a new feature. For those that dont know test dependencies. They had first been proposed by Markus Gälli based on an analysis of all Squeak tests years ago. He found that most tests cover a superset of another test's coverage set. A prototype in Java as been implemented later by Lea Hänsenberger and me. We published a case study at XP 2008, which lead to PHP folks to include test dependencies in the latest PHPUnit. The idea of explicit test dependencies is to shift the burden of isolating test cases from the developers to the framework. You avoid duplicate test code and you get less red test cases per failure. Please refer to Niko's blog post for more details [2].
We got some more ideas (such as API baseline testing, search in test results, etc...) but they will not likely make it into a first clean up.
One thing we do not know is how many folks are out there that depend on internal representation of SUnit. I talked to some folks and identified two requirements, first that legacy tests should keep running and second that contributions to other sunit forks should keep being mergeable. The first seems feasible, the second sounds like it boils down to not cleaning anything :)
What do you think?
cheers, AA
http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-exp...
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- View this message in context: http://n4.nabble.com/SUnit-tp1297972p1752629.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (15)
-
Adrian Kuhn -
Cameron Sanders -
csrabak＠bol.com.br -
Denis Kudriashov -
Gabriel Brunstein -
Julian Fitzell -
laurent laffont -
Lukas Renggli -
Mariano Martinez Peck -
Martin McClure -
Simon Denier -
Stan Shepherd -
Stéphane Ducasse -
Tudor Girba -
Yanni Chiu