Cleanup of SUnit is almost done. There are 179 tests with 75% coverage. Missing
are tests for the new resource setup and tests for the new history storage. Changes - uses announcements - new class factory DSL - does not print 'unexpected/expected' when empty - factored all assertions into TAssertable - copied Niall's 3-valued setup logic for test resources - new expectation matcher DSL - replaced history dictionary with proper class - keeps history as TestResult in memory - stores history as array in compiled methods - unexpected/expected linked with stored history - migrates #expectedDefects to stored history on the fly - bug fix: 'run failures/errors' updates history - bug fix: coverage is now able to cover itself - added flags for compatibility and deprecation - removed *a lot of* code duplication I tried to run *all* tests in the latest image with akuhn/SUnit and it seems to run fine. There are 5 failures and 2 errors (both with akuhn/SUnit and pharo/SUnit). The new test suite starts faster. You click and tests start running immediately! Progress: numClasses: 13 -> 19 numKLOC: 965 -> 1209 numMethods: 224 -> 291 numStatements: 3086 -> 3903 numTestCases: 51 -> 177 numTestKLOC: 591 -> 1200 numTestStatements: 2175 -> 4663 testCoverage: 61% -> 75% eventually, a SUnit with more test than production code! Give it a try and lemme know whether it runs with your tests. All your tests should still run. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load cheers, AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
s/chrismas/christmas/
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Kuhn
Hi Adrian,
> Gofer it > disablePackageCache; > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load Where is the update of Gofer that understand your expression? I tried with Gofer-AdrianLienhard.79 and Gofer-DamienCassou.88 from squeaksource.com/Pharo, but disablePackageCache: and package: are not understood. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> Where is the update of Gofer that understand your expression?
[ Gofer gofer load ] on: Error do: [ :err | err retry ]. Gofer gofer recompile. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Alexandre Bergel
Alexandre Bergel <alexandre@...> writes:
> > Gofer it > > disablePackageCache; > > squeaksource: 'akuhn'; > > package: 'SUnit'; > > package: 'SUnitGUI'; > > load > > Where is the update of Gofer that understand your > expression? See Lukas's mail. Alternatively use Gofer new "beware, might load wrong version from local cache with latest gofer!" squeaksource: 'akuhn'; addPackage: 'SUnit'; addPackage: 'SUnitGUI'; load the #disablePackageCache is only used to work around a glitch in the latest Gofer. (It attempts to load packages from the local cache that do *not* originate from akuhn. As it seems gofer always loads the package with the highest number independent of its origin. And keith's SUnit does have a higher version number than mine. You see the mess.) --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Kuhn
On Sun, Dec 27, 2009 at 4:03 AM, Adrian Kuhn <[hidden email]> wrote: Cleanup of SUnit is almost done. There are 179 tests with 75% coverage. Missing This is great :) I run all my SqueakDBX and GlorpDBX tests and I have one only problem: the expectedFailures are not working any more :( I put a halt are they are not even being called. All the rest seem to work (I have even test resources in both projects) Cheers Mariano Gofer it _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Adrian: Can I still bother you with new requirements ? jajaja
First of all, thank you very much for putting a context menu when you press "right button" over a failing or error test. I really hate when it was run again instead of opening a context menu. Now, I noticed that you open a menu with the options "History" "Store..." and "Show progress". I really love one item more called "browse it" and that opens a System Browser with that class, with that test method selected. What do you think? Cheers Mariano
On Mon, Dec 28, 2009 at 12:25 AM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
MMariano Martinez Peck <marianopeck@...> writes:
> This is great :) I run all my SqueakDBX and GlorpDBX tests Thanks for using it! > and I have one only problem: the expectedFailures are not working any more :( I put a halt are they are not even being called. All the rest seem to work (I have even test resources in both projects) Cannot reproduce that. Can you check which version of SUnit is loaded in your image? --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Mon, Dec 28, 2009 at 1:00 AM, Adrian Kuhn <[hidden email]> wrote: MMariano Martinez Peck <marianopeck@...> writes: thanks you for the develop :)
SUnit-AdrianKuhn.114 SUnitGUI-AdrianKuhn.57 As an example, I implement a instance side method of a test that doesn't extend directly from TestCase but from 2 o 3 in the middle that finally extends from TestCase: expectedFailures ^ (SqueakDatabaseAccessor DefaultDriver = SqueakDBXDriver) ifTrue: [ #(testBlob testBlobWithSubstring testLargeBlob)] ifFalse: [ #()]. HTH Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Mariano Martinez Peck <marianopeck@...> writes:
> As an example, I implement a instance side method of a test that doesn't > extend directly from TestCase but from 2 o 3 in the middle that finally > extends from TestCase: > > expectedFailures > ^ (SqueakDatabaseAccessor DefaultDriver = SqueakDBXDriver) > ifTrue: [ #(testBlob testBlobWithSubstring testLargeBlob)] > ifFalse: [ #()]. Oh, dynamically generated expected failures! Awesome, I did not think of that use. Currently they are copied once into the stored history and then ignored upon further runs. I'll fix that. --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
Mariano Martinez Peck <marianopeck@...> writes:
> Adrian: Can I still bother you with new requirements ? jajaja Your welcome :) > First of all, thank you very much for putting a context menu when you press > "right button" over a failing or error test. I really hate when it was run > again instead of opening a context menu. Now, I noticed that you open a menu > with the options "History" "Store..." and "Show progress". The history menu should *only* show up when you right-click in the colored status bar, but not on failure and error list. Can you conform that? > I really love one item more called "browse it" and that opens a System > Browser with that class, with that test method selected. What do you think? Awesome idea, I'll add that. PS, I was also thinking about a 'step through test' option that open a debugger at the start of the test, rather than at the failing assertions. Will add that to the same menu... --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Kuhn
Name: SUnit-AdrianKuhn.115
Author: AdrianKuhn Time: 28 December 2009, 2:22:16 am UUID: 21af8078-0c75-4323-89aa-5f0142fa09d4 Ancestors: SUnit-AdrianKuhn.114 Takes #expectedFailure into account. As required by Mariano Martinez Peck on the mailing list. He uses the #expectedFailure method to dynamically create expected failures, rather than a fixed set of failures as is stored in stored history. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Kuhn
Name: SUnitGUI-AdrianKuhn.58
Author: AdrianKuhn Time: 28 December 2009, 4:21:29 am UUID: 88a3fdcc-e794-4666-8f50-80be6c8afcf4 Ancestors: SUnitGUI-AdrianKuhn.57 Context menu for failures and errors. When you *right* click on a failure or error then a menu should show up. The menu offers to browse or debug the defect (as requested by Mariano Martinez Peck on the mailing list). As before, when you *left* click on a failure or error then it open ins the debugger. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Kuhn
Hi!
Apparently, expectedFailure has a different behavior from the original SUnit. I have a test method declared in a expectedFailures method. However, this test method does not fail, but it triggers a MNU. Running the unit test tells me there is 1 error, the method that I declared as expectedFailure. I guess this behavior is the right one. How can I fix this? There is no sender or implementer of expectedErrors. By the way, why TestCase>>expectedFailures is in the protocol 'history management'? There is also two empty method categories in TestCase. Cheers, Alexandre On 28 Dec 2009, at 02:27, Adrian Kuhn wrote: > Name: SUnit-AdrianKuhn.115 > Author: AdrianKuhn > Time: 28 December 2009, 2:22:16 am > UUID: 21af8078-0c75-4323-89aa-5f0142fa09d4 > Ancestors: SUnit-AdrianKuhn.114 > > Takes #expectedFailure into account. > > As required by Mariano Martinez Peck on the mailing list. He > uses the #expectedFailure method to dynamically create > expected failures, rather than a fixed set of failures as is > stored in stored history. > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Alexandre Bergel <alexandre@...> writes:
> Apparently, expectedFailure has a different behavior from the original > SUnit. Yes, now as you mention errors. In the original it has the (undocumented) behavior of declaring expected failures *and* errors. I'll see how I can fix that. > I have a test method declared in a expectedFailures method. However, > this test method does not fail, but it triggers a MNU. Running the > unit test tells me there is 1 error, the method that I declared as > expectedFailure. I guess this behavior is the right one. > > How can I fix this? There is no sender or implementer of expectedErrors. 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. > By the way, why TestCase>>expectedFailures is in the protocol 'history > management'? There is also two empty method categories in TestCase. The empty protocols are left overs of the old implementations. I dont know how to tell gofer/monticello to delete them. Do you know how? --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
>> Apparently, expectedFailure has a different behavior from the
>> original >> SUnit. > > Yes, now as you mention errors. In the original it has the > (undocumented) > behavior of declaring expected failures *and* errors. I'll see how I > can fix > that. Maybe introducing a method expectedErrors would do the thing. >> I have a test method declared in a expectedFailures method. However, >> this test method does not fail, but it triggers a MNU. Running the >> unit test tells me there is 1 error, the method that I declared as >> expectedFailure. I guess this behavior is the right one. >> >> How can I fix this? There is no sender or implementer of >> expectedErrors. > > 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? >> By the way, why TestCase>>expectedFailures is in the protocol >> 'history >> management'? There is also two empty method categories in TestCase. > > The empty protocols are left overs of the old implementations. I > dont know > how to tell gofer/monticello to delete them. Do you know how? No idea. But this looks like to be a bug in Monticello no? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Kuhn
Adrian I would love to see a videos of the new features you did :)
Stef (back writing and closing mail) On Dec 28, 2009, at 1:57 AM, Adrian Kuhn wrote: > Mariano Martinez Peck <marianopeck@...> writes: > >> Adrian: Can I still bother you with new requirements ? jajaja > > Your welcome :) > >> First of all, thank you very much for putting a context menu when you press >> "right button" over a failing or error test. I really hate when it was run >> again instead of opening a context menu. Now, I noticed that you open a menu >> with the options "History" "Store..." and "Show progress". > > The history menu should *only* show up when you right-click in the colored > status bar, but not on failure and error list. Can you conform that? > >> I really love one item more called "browse it" and that opens a System >> Browser with that class, with that test method selected. What do you think? > > Awesome idea, I'll add that. > > PS, I was also thinking about a 'step through test' option that open a debugger > at the start of the test, rather than at the failing assertions. Will add that > to the same menu... > > --AA > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Kuhn
On Mon, Dec 28, 2009 at 1:57 AM, Adrian Kuhn <[hidden email]> wrote:
I think that yes :) I attach an screenshot. Tell me is that's fine. In that screenshot you can see also the error tests that actually are expectedFailures and with the previous version of Sunit, the were green.
Excellent :) PS, I was also thinking about a 'step through test' option that open a debugger Yes, that's cool also. Many times I have to go to the assertion and then a restart in the debugger. Thank you very much. Mariano --AA _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Picture 2.png (477K) Download Attachment |
On Mon, Dec 28, 2009 at 12:33 PM, Mariano Martinez Peck <[hidden email]> wrote:
I now tested with your latests commits and it seems to work ok. Only the items "Browse" and "Debug" are shown over a failure/error test. And the other three ("History" "Store..." and "Show progress".) are only in the status bar :)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Kuhn
On Mon, Dec 28, 2009 at 2:27 AM, Adrian Kuhn <[hidden email]> wrote: Name: SUnit-AdrianKuhn.115 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, here: importExpectedFailures: aTestClass aTestClass new expectedFailures do: [ :each | self testFinished: (TestFinished new testClass: aTestClass; selector: each; outcome: TestFinished failures; yourself) ] 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. The versions I am using are: SUnit-AdrianKuhn.116 SUnitGUI-AdrianKuhn.58 Cheers Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |