From noreply at rubyforge.org Sun Nov 2 09:14:15 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 2 Nov 2008 09:14:15 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22602 ] assert_raise with no arguments and assert_raise_message Message-ID: <20081102141415.4E36D16780D7@rubyforge.org> Feature Requests item #22602, was opened at 2008-10-30 04:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: assert_raise with no arguments and assert_raise_message Initial Comment: Hi, I was just reading this article: http://programblings.com/2008/10/27/this-should_raise-an-exception/ He brings up two valid points. First, assert_raise with no arguments should default to [Exception], meaning you're just asserting that it raises _some_ error, but you don't care what kind. Second, there's no way to test for a particular error message. I've wanted this myself on a few occasions, so I think an "assert_raise_message" (or whatever you want to call it) would be handy. Regards, Dan ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-11-02 23:14 Message: Thanks for your suggestion. I've implemented in "assert_raise with no arguments should default to [Exception]" in trunk. Others are already in trunk. ---------------------------------------------------------------------- Comment By: Mathieu Martin (webmat) Date: 2008-10-30 06:58 Message: +1 from the whiner who wrote said article :-) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 From noreply at rubyforge.org Thu Nov 6 15:33:51 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Nov 2008 15:33:51 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22602 ] assert_raise with no arguments and assert_raise_message Message-ID: <20081106203351.5B30A185818F@rubyforge.org> Feature Requests item #22602, was opened at 2008-10-29 12:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 Category: None Group: None Status: Closed Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: assert_raise with no arguments and assert_raise_message Initial Comment: Hi, I was just reading this article: http://programblings.com/2008/10/27/this-should_raise-an-exception/ He brings up two valid points. First, assert_raise with no arguments should default to [Exception], meaning you're just asserting that it raises _some_ error, but you don't care what kind. Second, there's no way to test for a particular error message. I've wanted this myself on a few occasions, so I think an "assert_raise_message" (or whatever you want to call it) would be handy. Regards, Dan ---------------------------------------------------------------------- >Comment By: Daniel Berger (djberg96) Date: 2008-11-06 13:33 Message: Excellent! Any idea when you'll release 2.0.1? Thanks, Dan ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-02 07:14 Message: Thanks for your suggestion. I've implemented in "assert_raise with no arguments should default to [Exception]" in trunk. Others are already in trunk. ---------------------------------------------------------------------- Comment By: Mathieu Martin (webmat) Date: 2008-10-29 14:58 Message: +1 from the whiner who wrote said article :-) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 From noreply at rubyforge.org Thu Nov 6 18:04:53 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Nov 2008 18:04:53 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22602 ] assert_raise with no arguments and assert_raise_message Message-ID: <20081106230453.C3E461D780D1@rubyforge.org> Feature Requests item #22602, was opened at 2008-10-30 04:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 Category: None Group: None Status: Closed Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: assert_raise with no arguments and assert_raise_message Initial Comment: Hi, I was just reading this article: http://programblings.com/2008/10/27/this-should_raise-an-exception/ He brings up two valid points. First, assert_raise with no arguments should default to [Exception], meaning you're just asserting that it raises _some_ error, but you don't care what kind. Second, there's no way to test for a particular error message. I've wanted this myself on a few occasions, so I think an "assert_raise_message" (or whatever you want to call it) would be handy. Regards, Dan ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-11-07 08:04 Message: It will be released this weekend. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2008-11-07 05:33 Message: Excellent! Any idea when you'll release 2.0.1? Thanks, Dan ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-02 23:14 Message: Thanks for your suggestion. I've implemented in "assert_raise with no arguments should default to [Exception]" in trunk. Others are already in trunk. ---------------------------------------------------------------------- Comment By: Mathieu Martin (webmat) Date: 2008-10-30 06:58 Message: +1 from the whiner who wrote said article :-) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 From noreply at rubyforge.org Thu Nov 6 18:37:20 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Nov 2008 18:37:20 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22602 ] assert_raise with no arguments and assert_raise_message Message-ID: <20081106233720.398071D780D1@rubyforge.org> Feature Requests item #22602, was opened at 2008-10-29 12:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 Category: None Group: None Status: Closed Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: assert_raise with no arguments and assert_raise_message Initial Comment: Hi, I was just reading this article: http://programblings.com/2008/10/27/this-should_raise-an-exception/ He brings up two valid points. First, assert_raise with no arguments should default to [Exception], meaning you're just asserting that it raises _some_ error, but you don't care what kind. Second, there's no way to test for a particular error message. I've wanted this myself on a few occasions, so I think an "assert_raise_message" (or whatever you want to call it) would be handy. Regards, Dan ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2008-11-06 15:37 Message: Test::Exception (from perl's CPAN) has functionality like this and a clean, easy to understand implementation; perhaps this could be used as a basis. http://search.cpan.org/~adie/Test-Exception-0.27/lib/Test/Exception.pm Look at throws_ok in the docs. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-06 15:04 Message: It will be released this weekend. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2008-11-06 12:33 Message: Excellent! Any idea when you'll release 2.0.1? Thanks, Dan ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-02 06:14 Message: Thanks for your suggestion. I've implemented in "assert_raise with no arguments should default to [Exception]" in trunk. Others are already in trunk. ---------------------------------------------------------------------- Comment By: Mathieu Martin (webmat) Date: 2008-10-29 14:58 Message: +1 from the whiner who wrote said article :-) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 From noreply at rubyforge.org Thu Nov 6 21:29:19 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Nov 2008 21:29:19 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22602 ] assert_raise with no arguments and assert_raise_message Message-ID: <20081107022920.1844318581AE@rubyforge.org> Feature Requests item #22602, was opened at 2008-10-30 04:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 Category: None Group: None Status: Closed Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: assert_raise with no arguments and assert_raise_message Initial Comment: Hi, I was just reading this article: http://programblings.com/2008/10/27/this-should_raise-an-exception/ He brings up two valid points. First, assert_raise with no arguments should default to [Exception], meaning you're just asserting that it raises _some_ error, but you don't care what kind. Second, there's no way to test for a particular error message. I've wanted this myself on a few occasions, so I think an "assert_raise_message" (or whatever you want to call it) would be handy. Regards, Dan ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-11-07 11:29 Message: ? All functionalities have been implemented. Does it mean that there are some functionalities what throws_ok has but Test::Unit does not have? ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2008-11-07 08:37 Message: Test::Exception (from perl's CPAN) has functionality like this and a clean, easy to understand implementation; perhaps this could be used as a basis. http://search.cpan.org/~adie/Test-Exception-0.27/lib/Test/Exception.pm Look at throws_ok in the docs. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-07 08:04 Message: It will be released this weekend. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2008-11-07 05:33 Message: Excellent! Any idea when you'll release 2.0.1? Thanks, Dan ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-02 23:14 Message: Thanks for your suggestion. I've implemented in "assert_raise with no arguments should default to [Exception]" in trunk. Others are already in trunk. ---------------------------------------------------------------------- Comment By: Mathieu Martin (webmat) Date: 2008-10-30 06:58 Message: +1 from the whiner who wrote said article :-) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 From noreply at rubyforge.org Thu Nov 6 23:07:23 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Nov 2008 23:07:23 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22602 ] assert_raise with no arguments and assert_raise_message Message-ID: <20081107040723.7BA5D18582B4@rubyforge.org> Feature Requests item #22602, was opened at 2008-10-29 12:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 Category: None Group: None Status: Closed Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: assert_raise with no arguments and assert_raise_message Initial Comment: Hi, I was just reading this article: http://programblings.com/2008/10/27/this-should_raise-an-exception/ He brings up two valid points. First, assert_raise with no arguments should default to [Exception], meaning you're just asserting that it raises _some_ error, but you don't care what kind. Second, there's no way to test for a particular error message. I've wanted this myself on a few occasions, so I think an "assert_raise_message" (or whatever you want to call it) would be handy. Regards, Dan ---------------------------------------------------------------------- >Comment By: Daniel Berger (djberg96) Date: 2008-11-06 21:07 Message: I don't see anything in Test::Exception that's not in test-unit 2.0.1. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-06 19:29 Message: ? All functionalities have been implemented. Does it mean that there are some functionalities what throws_ok has but Test::Unit does not have? ---------------------------------------------------------------------- Comment By: Erik Hollensbe (erikh) Date: 2008-11-06 16:37 Message: Test::Exception (from perl's CPAN) has functionality like this and a clean, easy to understand implementation; perhaps this could be used as a basis. http://search.cpan.org/~adie/Test-Exception-0.27/lib/Test/Exception.pm Look at throws_ok in the docs. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-06 16:04 Message: It will be released this weekend. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2008-11-06 13:33 Message: Excellent! Any idea when you'll release 2.0.1? Thanks, Dan ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-02 07:14 Message: Thanks for your suggestion. I've implemented in "assert_raise with no arguments should default to [Exception]" in trunk. Others are already in trunk. ---------------------------------------------------------------------- Comment By: Mathieu Martin (webmat) Date: 2008-10-29 14:58 Message: +1 from the whiner who wrote said article :-) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22602&group_id=5650 From noreply at rubyforge.org Sun Nov 9 08:06:22 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 9 Nov 2008 08:06:22 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Bugs-22723 ] collector fails on anonymous classes Message-ID: <20081109130622.6C4E718581B8@rubyforge.org> Bugs item #22723, was opened at 2008-11-09 05:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22723&group_id=5650 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Erik Hollensbe (erikh) Assigned to: Nobody (None) Summary: collector fails on anonymous classes Initial Comment: In a couple of places in DBI (to test against the different databases), I need to create several anonymous classes multiple times to re-use them. Test::Unit used to have no problem with this. Now, this code exists in collector.rb: def sort(suites) suites.sort_by{|s| s.name} end The Class#name returns nil for classes that weren't defined at compile-time. This fails horribly when dealing with classes defined with Class.new. Would it be sane enough to suggest: def sort(suites) suites.sort_by {|s| s.name} rescue suites end Which would make me happy (I'd prefer to control suite ordering myself anyways, at least in something that has esoteric testing needs like DBI) and still keep the existing functionality for the common case. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22723&group_id=5650 From noreply at rubyforge.org Sun Nov 9 08:54:30 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 9 Nov 2008 08:54:30 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Bugs-22723 ] collector fails on anonymous classes Message-ID: <20081109135430.53F5118582B4@rubyforge.org> Bugs item #22723, was opened at 2008-11-09 22:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22723&group_id=5650 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Erik Hollensbe (erikh) Assigned to: Nobody (None) Summary: collector fails on anonymous classes Initial Comment: In a couple of places in DBI (to test against the different databases), I need to create several anonymous classes multiple times to re-use them. Test::Unit used to have no problem with this. Now, this code exists in collector.rb: def sort(suites) suites.sort_by{|s| s.name} end The Class#name returns nil for classes that weren't defined at compile-time. This fails horribly when dealing with classes defined with Class.new. Would it be sane enough to suggest: def sort(suites) suites.sort_by {|s| s.name} rescue suites end Which would make me happy (I'd prefer to control suite ordering myself anyways, at least in something that has esoteric testing needs like DBI) and still keep the existing functionality for the common case. ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-11-09 22:54 Message: I've fixed in trunk. Class#to_s will be used as fallback of Class#name. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22723&group_id=5650 From noreply at rubyforge.org Sun Nov 9 09:23:29 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 9 Nov 2008 09:23:29 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Bugs-22723 ] collector fails on anonymous classes Message-ID: <20081109142329.9160A185859A@rubyforge.org> Bugs item #22723, was opened at 2008-11-09 05:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22723&group_id=5650 Category: None Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Erik Hollensbe (erikh) Assigned to: Nobody (None) Summary: collector fails on anonymous classes Initial Comment: In a couple of places in DBI (to test against the different databases), I need to create several anonymous classes multiple times to re-use them. Test::Unit used to have no problem with this. Now, this code exists in collector.rb: def sort(suites) suites.sort_by{|s| s.name} end The Class#name returns nil for classes that weren't defined at compile-time. This fails horribly when dealing with classes defined with Class.new. Would it be sane enough to suggest: def sort(suites) suites.sort_by {|s| s.name} rescue suites end Which would make me happy (I'd prefer to control suite ordering myself anyways, at least in something that has esoteric testing needs like DBI) and still keep the existing functionality for the common case. ---------------------------------------------------------------------- >Comment By: Erik Hollensbe (erikh) Date: 2008-11-09 06:23 Message: Works for me. Thanks for addressing this! ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-09 05:54 Message: I've fixed in trunk. Class#to_s will be used as fallback of Class#name. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22723&group_id=5650 From noreply at rubyforge.org Tue Nov 18 21:31:58 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Nov 2008 21:31:58 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22884 ] Raise an error if duplicate test found Message-ID: <20081119023158.9235F185859A@rubyforge.org> Feature Requests item #22884, was opened at 2008-11-18 19:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22884&group_id=5650 Category: None Group: None Status: Open Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Raise an error if duplicate test found Initial Comment: Hi, I've always found it annoying that creating duplicate tests doesn't raise any sort of warning or error by default. Occasionally I make a copy/paste mistake, and I have to rely on running my tests in verbose/warning mode to catch them. However, many users don't do that and are none the wiser. Consider this code. I've done something similar by mistake in the past. require 'rubygems' gem 'test-unit' require 'test/unit' class TC_Foo < Test::Unit::TestCase def test_foo assert_true(1 == 1) end def test_foo assert_true(1 == 1) end end That will work fine, but the output suggests that only one test was run. I would like to see duplicate tests (within the same class) either automatically generate a warning or raise an error, since I can't think of a situation where users would want to re-use the same test name. What do you think? Regards, Dan ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22884&group_id=5650 From noreply at rubyforge.org Tue Nov 18 21:41:26 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Nov 2008 21:41:26 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22884 ] Raise an error if duplicate test found Message-ID: <20081119024126.37BFB185859A@rubyforge.org> Feature Requests item #22884, was opened at 2008-11-19 11:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22884&group_id=5650 Category: None Group: None Status: Open Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Raise an error if duplicate test found Initial Comment: Hi, I've always found it annoying that creating duplicate tests doesn't raise any sort of warning or error by default. Occasionally I make a copy/paste mistake, and I have to rely on running my tests in verbose/warning mode to catch them. However, many users don't do that and are none the wiser. Consider this code. I've done something similar by mistake in the past. require 'rubygems' gem 'test-unit' require 'test/unit' class TC_Foo < Test::Unit::TestCase def test_foo assert_true(1 == 1) end def test_foo assert_true(1 == 1) end end That will work fine, but the output suggests that only one test was run. I would like to see duplicate tests (within the same class) either automatically generate a warning or raise an error, since I can't think of a situation where users would want to re-use the same test name. What do you think? Regards, Dan ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-11-19 11:41 Message: What about '$VERBOSE = true'? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22884&group_id=5650 From noreply at rubyforge.org Tue Nov 25 09:05:17 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 25 Nov 2008 09:05:17 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Bugs-22986 ] Test names with '?' blow up on Windows Message-ID: <20081125140517.B582018581B0@rubyforge.org> Bugs item #22986, was opened at 2008-11-25 07:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22986&group_id=5650 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Test names with '?' blow up on Windows Initial Comment: Hi, Test::Unit 2.0.1 Windows XP Pro I stumbled on this one by accident. If I have a test method with a '?' in it, it fails with Errno::EINVAL error. This happens because Test::Unit is trying to write a file with an identical name to the .test-result directory, but the '?' character is illegal in Windows file names: def test_boolean? assert_true(1 == 1) end 1) Error: test_is_executable_real?(TC_File_Stat): Errno::EINVAL: Invalid argument - C:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake/.test-result/TC _File_Stat/test_is_executable_real? C:/ruby/lib/ruby/1.8/fileutils.rb:243:in `mkdir' C:/ruby/lib/ruby/1.8/fileutils.rb:243:in `fu_mkdir' C:/ruby/lib/ruby/1.8/fileutils.rb:217:in `mkdir_p' C:/ruby/lib/ruby/1.8/fileutils.rb:215:in `reverse_each' C:/ruby/lib/ruby/1.8/fileutils.rb:215:in `mkdir_p' C:/ruby/lib/ruby/1.8/fileutils.rb:201:in `each' C:/ruby/lib/ruby/1.8/fileutils.rb:201:in `mkdir_p' Possible solutions are to simply declare '?' illegal in test method names (raising an error up front), to strip them on the fly, or to replace them with text like '_qm' (question mark) when writing the file. Regards, Dan ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22986&group_id=5650 From noreply at rubyforge.org Tue Nov 25 09:52:32 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 25 Nov 2008 09:52:32 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22988 ] Provide a .test-result cleanup hook Message-ID: <20081125145232.435AE18585C9@rubyforge.org> Feature Requests item #22988, was opened at 2008-11-25 07:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650 Category: None Group: None Status: Open Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Provide a .test-result cleanup hook Initial Comment: Hi, Can you please provide a hook for cleaning up (deleting) the .test-result directory when all tests are finished? I think something users could put directly in the shutdown method would be ideal. My apologies if something like this already exists, but I didn't see it. Regards, Dan ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650 From noreply at rubyforge.org Wed Nov 26 06:40:27 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Nov 2008 06:40:27 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Bugs-22986 ] Test names with '?' blow up on Windows Message-ID: <20081126114027.3EA0418585C9@rubyforge.org> Bugs item #22986, was opened at 2008-11-25 23:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22986&group_id=5650 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Test names with '?' blow up on Windows Initial Comment: Hi, Test::Unit 2.0.1 Windows XP Pro I stumbled on this one by accident. If I have a test method with a '?' in it, it fails with Errno::EINVAL error. This happens because Test::Unit is trying to write a file with an identical name to the .test-result directory, but the '?' character is illegal in Windows file names: def test_boolean? assert_true(1 == 1) end 1) Error: test_is_executable_real?(TC_File_Stat): Errno::EINVAL: Invalid argument - C:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake/.test-result/TC _File_Stat/test_is_executable_real? C:/ruby/lib/ruby/1.8/fileutils.rb:243:in `mkdir' C:/ruby/lib/ruby/1.8/fileutils.rb:243:in `fu_mkdir' C:/ruby/lib/ruby/1.8/fileutils.rb:217:in `mkdir_p' C:/ruby/lib/ruby/1.8/fileutils.rb:215:in `reverse_each' C:/ruby/lib/ruby/1.8/fileutils.rb:215:in `mkdir_p' C:/ruby/lib/ruby/1.8/fileutils.rb:201:in `each' C:/ruby/lib/ruby/1.8/fileutils.rb:201:in `mkdir_p' Possible solutions are to simply declare '?' illegal in test method names (raising an error up front), to strip them on the fly, or to replace them with text like '_qm' (question mark) when writing the file. Regards, Dan ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-11-26 20:40 Message: Thanks for reporting. I've fixed in trunk. I was implemented Test::Unit::Priority::Checker#escaped_method_name but it isn't used... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=22986&group_id=5650 From noreply at rubyforge.org Wed Nov 26 06:43:15 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Nov 2008 06:43:15 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22988 ] Provide a .test-result cleanup hook Message-ID: <20081126114315.A097318585AA@rubyforge.org> Feature Requests item #22988, was opened at 2008-11-25 23:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650 Category: None Group: None Status: Open Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Provide a .test-result cleanup hook Initial Comment: Hi, Can you please provide a hook for cleaning up (deleting) the .test-result directory when all tests are finished? I think something users could put directly in the shutdown method would be ideal. My apologies if something like this already exists, but I didn't see it. Regards, Dan ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-11-26 20:43 Message: Uhm... We can't delete the .test-result directory because the directory is used in the next test run. If we delete the .test-result, all tests will be ran because they are treated as not passed tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650 From noreply at rubyforge.org Wed Nov 26 06:44:51 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Nov 2008 06:44:51 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22884 ] Raise an error if duplicate test found Message-ID: <20081126114451.58E3818586DA@rubyforge.org> Feature Requests item #22884, was opened at 2008-11-19 11:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22884&group_id=5650 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Raise an error if duplicate test found Initial Comment: Hi, I've always found it annoying that creating duplicate tests doesn't raise any sort of warning or error by default. Occasionally I make a copy/paste mistake, and I have to rely on running my tests in verbose/warning mode to catch them. However, many users don't do that and are none the wiser. Consider this code. I've done something similar by mistake in the past. require 'rubygems' gem 'test-unit' require 'test/unit' class TC_Foo < Test::Unit::TestCase def test_foo assert_true(1 == 1) end def test_foo assert_true(1 == 1) end end That will work fine, but the output suggests that only one test was run. I would like to see duplicate tests (within the same class) either automatically generate a warning or raise an error, since I can't think of a situation where users would want to re-use the same test name. What do you think? Regards, Dan ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-11-26 20:44 Message: I will close this bug. If you can't resolve this problem by $VERBOSE, please open a new bug. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-19 11:41 Message: What about '$VERBOSE = true'? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22884&group_id=5650 From noreply at rubyforge.org Wed Nov 26 07:17:37 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Nov 2008 07:17:37 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22988 ] Provide a .test-result cleanup hook Message-ID: <20081126121737.6716618585EF@rubyforge.org> Feature Requests item #22988, was opened at 2008-11-25 07:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650 Category: None Group: None Status: Open Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Provide a .test-result cleanup hook Initial Comment: Hi, Can you please provide a hook for cleaning up (deleting) the .test-result directory when all tests are finished? I think something users could put directly in the shutdown method would be ideal. My apologies if something like this already exists, but I didn't see it. Regards, Dan ---------------------------------------------------------------------- >Comment By: Daniel Berger (djberg96) Date: 2008-11-26 05:17 Message: I understand. I was asking for something that would be optional. Hm, can an alternative directory location be specified? Thanks, Dan ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-26 04:43 Message: Uhm... We can't delete the .test-result directory because the directory is used in the next test run. If we delete the .test-result, all tests will be ran because they are treated as not passed tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650 From noreply at rubyforge.org Wed Nov 26 07:21:18 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Nov 2008 07:21:18 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22884 ] Raise an error if duplicate test found Message-ID: <20081126122119.9636A18585EF@rubyforge.org> Feature Requests item #22884, was opened at 2008-11-18 19:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22884&group_id=5650 Category: None Group: None Status: Closed Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Raise an error if duplicate test found Initial Comment: Hi, I've always found it annoying that creating duplicate tests doesn't raise any sort of warning or error by default. Occasionally I make a copy/paste mistake, and I have to rely on running my tests in verbose/warning mode to catch them. However, many users don't do that and are none the wiser. Consider this code. I've done something similar by mistake in the past. require 'rubygems' gem 'test-unit' require 'test/unit' class TC_Foo < Test::Unit::TestCase def test_foo assert_true(1 == 1) end def test_foo assert_true(1 == 1) end end That will work fine, but the output suggests that only one test was run. I would like to see duplicate tests (within the same class) either automatically generate a warning or raise an error, since I can't think of a situation where users would want to re-use the same test name. What do you think? Regards, Dan ---------------------------------------------------------------------- >Comment By: Daniel Berger (djberg96) Date: 2008-11-26 05:21 Message: I realize it can be solved with $VERBOSE, but many users don't realize this. In some cases $VERBOSE is impractical. With Ruby on Rails, for example, a duplicate test name warning would be lost in an avalanche of other warnings (which is why I don't use it in RoR tests). Regards, Dan PS - I didn't see your first response until today. I think the RF mailer is having issues lately. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-26 04:44 Message: I will close this bug. If you can't resolve this problem by $VERBOSE, please open a new bug. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-18 19:41 Message: What about '$VERBOSE = true'? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22884&group_id=5650 From noreply at rubyforge.org Wed Nov 26 07:32:26 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Nov 2008 07:32:26 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22988 ] Provide a .test-result cleanup hook Message-ID: <20081126123226.6644218585ED@rubyforge.org> Feature Requests item #22988, was opened at 2008-11-25 23:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650 Category: None Group: None Status: Open Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Provide a .test-result cleanup hook Initial Comment: Hi, Can you please provide a hook for cleaning up (deleting) the .test-result directory when all tests are finished? I think something users could put directly in the shutdown method would be ideal. My apologies if something like this already exists, but I didn't see it. Regards, Dan ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-11-26 21:32 Message: There is no option for that. Should I add an option for that? What is the problem for now? ".test-result" directory name? IMHO, I want to work the priority mode feature intelligently (maybe implicitly) ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2008-11-26 21:17 Message: I understand. I was asking for something that would be optional. Hm, can an alternative directory location be specified? Thanks, Dan ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-26 20:43 Message: Uhm... We can't delete the .test-result directory because the directory is used in the next test run. If we delete the .test-result, all tests will be ran because they are treated as not passed tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650 From noreply at rubyforge.org Wed Nov 26 08:05:15 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Nov 2008 08:05:15 -0500 (EST) Subject: [test-unit-tracker] [ test-unit-Feature Requests-22988 ] Provide a .test-result cleanup hook Message-ID: <20081126130515.AB13F18581B0@rubyforge.org> Feature Requests item #22988, was opened at 2008-11-25 07:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650 Category: None Group: None Status: Open Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: Provide a .test-result cleanup hook Initial Comment: Hi, Can you please provide a hook for cleaning up (deleting) the .test-result directory when all tests are finished? I think something users could put directly in the shutdown method would be ideal. My apologies if something like this already exists, but I didn't see it. Regards, Dan ---------------------------------------------------------------------- >Comment By: Daniel Berger (djberg96) Date: 2008-11-26 06:05 Message: Hi, I use Eclipse as my IDE, mainly for project management, so when the .test-result files are generated, it causes my project to get out of sync with my remote source control manager. If I can store them somewhere else, I wouldn't have to remember to manually delete them before committing, tagging, etc. It's not a major issue, though. I just thought it would be nice to have a hook to go clean them up automatically. I suppose I could just custom code as part of a 'rake clean' task. I think making priority mode implicit would be a mistake. I sometimes refactor tests after I've written them. If I update a test, it wouldn't get re-run unless I force it. Regards, Dan ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-26 05:32 Message: There is no option for that. Should I add an option for that? What is the problem for now? ".test-result" directory name? IMHO, I want to work the priority mode feature intelligently (maybe implicitly) ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2008-11-26 05:17 Message: I understand. I was asking for something that would be optional. Hm, can an alternative directory location be specified? Thanks, Dan ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-11-26 04:43 Message: Uhm... We can't delete the .test-result directory because the directory is used in the next test run. If we delete the .test-result, all tests will be ran because they are treated as not passed tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=22988&group_id=5650