- Pharo-dev - lists.pharo.org

[Pharo-project] Tests of OmniBrowser

by Mariano Martinez Peck

Hi Colin! I saw you were committing in the OmniBrowser tests. I am interested in loading these tests in Pharo (optionally). But I am not sure which packages to include and their state. Right now, in our Pharo images we are loading the following packages from http://source.wiresong.ca/ob package: 'OmniBrowser'; package: 'OB-Morphic'; package: 'OB-Standard'; package: 'OB-Refactory'; package: 'OB-Regex'; package: 'OB-SUnitIntegration'; package: 'OB-Shout'; I saw the following tests packages: OB-Tests-Core OB-Tests-Morphic OB-Tests-Standard There are more related to the packages we are including? should these test be all green? Thank you very much. Mariano

Dec. 28, 2009

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

by Adrian Kuhn

Alexandre Bergel <alexandre@...> writes: > > The stored history is compiled into a method on the class side. So you get > > the exact benefit of #expectedFailures/#expectedError. It is persistent > > across source control and will mark your failures/errors as expected. So > > you dont need #expectedError at all. > > Yep, I know this, I pair programmed the history mechanism with Simon > But I still do not understand how do you distinguish a method that > always fails from an expectedFailure (i.e., a method that I know will > fail, but I do not want it to make my unit test red)? > If we need expectedFailure, we will probably need expectedError no? This is an aspect that I changed. An outcome is unexpected if and only if it does not match what is in the stored history. (For compatibility only #expectedFailures are added to the stored history.) So the preferred way to mark an outcome as unexpected is to store the history. Try it - remove #expectedFailures - run all your tests (you'll get failures and errors, -> not green) - store the history - run all your tests again (all your defects are expected, -> green) And just for demonstration - introduce a new defect - run all your tests again (one unexpected defect, -> not green) Does this match your workflow? --AA

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by StÃ©phane Ducasse

> I don't think that growing a Set is faster than growing an Array, then >>> converting it to a Set, but let's see the numbers: >>> >>> "Prepare an array with 10000 elements, each element is an array with one >>> integer. 10% is duplicate." >> >> This is something I can understand. So we will fix that. > > This is rather a matter of memory. The use case in Moose back then used to be > closer to 10 million objects with a set of eventual size of 100 element. So > the intend is to avoid allocating 40 MB of memory when all you need is a set > of 100 elements. So at least in Moose, you should keep it :) Context :) Thanks. I will add a comment to flatCollectAsSet: going in that direction. Stef

Dec. 28, 2009

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

by Alexandre Bergel

This is really cool that you work on SUnit. This is really needed. Cheers, Alexandre On 28 Dec 2009, at 18:47, Alexandre Bergel wrote: >>>> The preferred way is to store your results into the stored >>>> history. You can >>>> store the history with the context menu in the test runner. To do >>>> so, right >>>> click in the colored status field and choose `store history`. The >>>> stored >>>> results are treated as the expected results then. >>> >>> Yes, but... how is this related to the expectedError? >> >> The stored history is compiled into a method on the class side. So >> you get the >> exact benefit of #expectedFailures/#expectedError. It is persistent >> across >> source control and will mark your failures/errors as expected. So >> you dont >> need #expectedError at all. > > Yep, I know this, I pair programmed the history mechanism with > Simon :-) > But I still do not understand how do you distinguish a method that > always fails from an expectedFailure (i.e., a method that I know will > fail, but I do not want it to make my unit test red)? > If we need expectedFailure, we will probably need expectedError no? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, chrisma edition :)

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > Adrian I would love to see a videos of the new features you did :) A blog post is in work... --AA -- 2nd Workshop on Source Code Search etc. Submit papers by January 19, 2010. http://bit.ly/suite2010

Dec. 28, 2009

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

by Alexandre Bergel

>>> The preferred way is to store your results into the stored >>> history. You can >>> store the history with the context menu in the test runner. To do >>> so, right >>> click in the colored status field and choose `store history`. The >>> stored >>> results are treated as the expected results then. >> >> Yes, but... how is this related to the expectedError? > > The stored history is compiled into a method on the class side. So > you get the > exact benefit of #expectedFailures/#expectedError. It is persistent > across > source control and will mark your failures/errors as expected. So > you dont > need #expectedError at all. Yep, I know this, I pair programmed the history mechanism with Simon :-) But I still do not understand how do you distinguish a method that always fails from an expectedFailure (i.e., a method that I know will fail, but I do not want it to make my unit test red)? If we need expectedFailure, we will probably need expectedError no? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 28, 2009

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

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 6:42 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Mariano Martinez Peck <marianopeck@...> writes: > > > Hi Adrian! Thanks for trying to fix this. However, I can still reproduce > the > > problem. I put a halt in my expectedFailures method and it is being > called > > [..] The iteration throught the do: seems to be ok, but I don't know why, > > the tests are still considered as error (red) instead of expectedFailures > in > > green. Is correct to put "outcome: TestFinished failures;" ??? I > guess > > it would be something like "outcome: TestFinished expectedFailures" but I > > look in the class side methods of TestFinished and I only see passed, > failure > > and error. Let me know if I can test something more. > > I see, you got the same case as Alex. > > You declared an expected *error* in #expectedFailures. That used to work > with > the old SUnit but the new SUnit takes you literally and expects it to be a > failure and a failure only. I will work on a solution for that. > Ahhh yes, sorry. I just discovered that. Wait...I will suggest this: It is true what you said about expectedFailure is expected failure and not expected error. I just did it like that because I thought it was like that. But now that I see it, that is probably wrong. So, what I would do is to "fix" it but (I don't know) put is as deprecated so that all the tests of the people are still green and give them time to change it to expectedErrors or similar. After a second release you can remove this fix :) What do you think ? Cheers Mariano > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

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

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > Hi Adrian! Thanks for trying to fix this. However, I can still reproduce the > problem. I put a halt in my expectedFailures method and it is being called > [..] The iteration throught the do: seems to be ok, but I don't know why, > the tests are still considered as error (red) instead of expectedFailures in > green. Is correct to put "outcome: TestFinished failures;" ??? I guess > it would be something like "outcome: TestFinished expectedFailures" but I > look in the class side methods of TestFinished and I only see passed, failure > and error. Let me know if I can test something more. I see, you got the same case as Alex. You declared an expected *error* in #expectedFailures. That used to work with the old SUnit but the new SUnit takes you literally and expects it to be a failure and a failure only. I will work on a solution for that. --AA

Dec. 28, 2009

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

by Adrian Kuhn

Alexandre Bergel <alexandre@...> writes: > > The preferred way is to store your results into the stored history. You can > > store the history with the context menu in the test runner. To do so, right > > click in the colored status field and choose `store history`. The stored > > results are treated as the expected results then. > > Yes, but... how is this related to the expectedError? The stored history is compiled into a method on the class side. So you get the exact benefit of #expectedFailures/#expectedError. It is persistent across source control and will mark your failures/errors as expected. So you dont need #expectedError at all. The history system has two levels - "history" is put in a class variable on the class side. This information is used for the browser icons by OB and O2, such that you can see the result of the latest test run. This information is local to your image. - "stored history" is put into a compiled method on the class side. This information is used by the test runner to mark unexpected passes and expected defects (failures, errors *and* any custom defects). This information is global and persists together with your source code. Programatically they are accessible with `testClass history` and `testClass storedHistory`, and `testClass storeHistoryIntoCompiledMethod` will put the current history into stored history. Marking of unexpected results can be done between *any* two test results with `testResult markUnexpectedResults: anotherTestResult`, so other tools builders are free to compare any two results. Also you can define your very own test results (eg `aTestFinished outcome: #ignored`) and they will be processed by result marking. --AA

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > > I don't think that growing a Set is faster than growing an Array, then > > converting it to a Set, but let's see the numbers: > > > > "Prepare an array with 10000 elements, each element is an array with one > > integer. 10% is duplicate." > > This is something I can understand. So we will fix that. This is rather a matter of memory. The use case in Moose back then used to be closer to 10 million objects with a set of eventual size of 100 element. So the intend is to avoid allocating 40 MB of memory when all you need is a set of 100 elements. So at least in Moose, you should keep it :) --AA

Dec. 28, 2009