From noreply at rubyforge.org Fri Sep 12 15:39:38 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 12 Sep 2008 15:39:38 -0400 (EDT) Subject: [test-unit-tracker] [ test-unit-Bugs-21939 ] startup and shutdown methods not documented by RDoc Message-ID: <20080912193938.22BDA18581A7@rubyforge.org> Bugs item #21939, was opened at 2008-09-12 12:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=21939&group_id=5650 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: startup and shutdown methods not documented by RDoc Initial Comment: Hi, test-unit 2.0.0 Ruby 1.8.6 It doesn't look to me like the startup and shutdown methods got picked up my rdoc when the gem was installed. I see the other new methods (omit, etc), but not those two. Can you please make sure they get picked up? Thanks, Dan ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=21939&group_id=5650 From noreply at rubyforge.org Fri Sep 12 21:48:42 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 12 Sep 2008 21:48:42 -0400 (EDT) Subject: [test-unit-tracker] [ test-unit-Bugs-21939 ] startup and shutdown methods not documented by RDoc Message-ID: <20080913014842.9AB4318581AC@rubyforge.org> Bugs item #21939, was opened at 2008-09-13 04:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=21939&group_id=5650 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Daniel Berger (djberg96) Assigned to: Nobody (None) Summary: startup and shutdown methods not documented by RDoc Initial Comment: Hi, test-unit 2.0.0 Ruby 1.8.6 It doesn't look to me like the startup and shutdown methods got picked up my rdoc when the gem was installed. I see the other new methods (omit, etc), but not those two. Can you please make sure they get picked up? Thanks, Dan ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-09-13 10:48 Message: They are in Test::Unit::TestCase description. But I've added empty methods, Test::Unit::TestCase.{startup,shutdown}, to just add RDoc. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21856&aid=21939&group_id=5650 From noreply at rubyforge.org Fri Sep 12 23:20:12 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 12 Sep 2008 23:20:12 -0400 (EDT) Subject: [test-unit-tracker] [ test-unit-Feature Requests-20851 ] New Assertions Message-ID: <20080913032013.0A1DD18581AC@rubyforge.org> Feature Requests item #20851, was opened at 2008-06-27 13:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=20851&group_id=5650 Category: None Group: None Status: Open Priority: 3 Submitted By: Designing Patterns (designingpatts) Assigned to: Nobody (None) Summary: New Assertions Initial Comment: I packaged some assertions that I found useful in a gem (http://assertions.rubyforge.org), and I think that they may be generally useful enough to be included with the standard Test::Unit. The assertions currently in the library are: assert_raise_message: Verifies that a specified error is raised and that it has a specified error message. assert_not: Verifies that the argument is false or nil asesrt_greater_than: Verifies that the first argument is greater than the second argument. Also assert_less_than, assert_greater_than_or_equal_to, assert_less_than_or_equal_to. I think that these are clearer than assert_operator. assert_fail: Verifies that a given block has an assertion that fails (useful for testing new assertions) ---------------------------------------------------------------------- >Comment By: Kouhei Sutou (kou) Date: 2008-09-13 12:20 Message: assert_raise_message: What about pass an exception instance to assert_raise? expected_exception = RuntimeError.new("some message") assert_raise(expected_exception) do raise "some message" end assert_compare: implemented in trunk. Thanks! assert_fail: What about assert_fail_assertion? ---------------------------------------------------------------------- Comment By: Designing Patterns (designingpatts) Date: 2008-08-22 06:38 Message: Given the choice between: assert_compare(a, "<", b) and assert_compare(a, "lt", b) I probably would use the former. I don't think that the latter has the brevity or clarity of assert_lt.... ---------------------------------------------------------------------- Comment By: Designing Patterns (designingpatts) Date: 2008-08-22 06:33 Message: assert_raise_message also could be named something like assert_raise_and_message or assert_raise_with_message... I think that passing in arrays to assert_raise makes the interface a bit messy... Regarding the example with assert_fail, I think that 'fail' should be clear enough from the context. As I mentioned before, assert_assertion_fail or assert_failed_assertion or some variant also could be used as a name, but I think that it might be overkill. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-08-10 10:48 Message: We can also specify just an exception class and message pair to assert_raise. It seems that assert_raise_message name feels checking just an exception message (an exception class is excluded). What about assert_compare(x, "<", y), assert_compare(x, "gt", y), assert_compare(x, "greater-than", y), ...? (or assert_comparison) I was thinking about the following situation: class TestDB < Test::Unit::TestCase def test_connection assert_fail do DB.connect("wrong user name", "wrong password") end end def assert_fail assert_raise(DB::ConnectionFailedError, &block) end end In the test case context, it seems that 'fail' means connection failure. ---------------------------------------------------------------------- Comment By: Designing Patterns (designingpatts) Date: 2008-08-05 01:29 Message: I guess that allowing Array arguments to assert_raise would be fine in order to implement verification of the error message... It's a bit weird, though, as I'm not sure that it makes sense to allow multiple error classes and messages to be asserted at the same time with assert_raise. Wouldn't a good test only assert a single error message? assert_raise_message also allows you to prefix a string to the failed assertion message, as many of the other assertion methods do. Instead of assert_operator, the method could be called assert_compare or assert_comparison. I don't have any hard figures with which to justify the assert_greater_than family of methods. My previous employer had them (and the assert_gt, assert_le, ... shorter aliases) The shorter aliases (assert_gt, assert_le, and assert_lt) probably will be very clear for some people, as some programming languages use gt instead of >, lt instead of <, le instead of <=, ... (Fortran, for example). I think that assert_fail is pretty clear, given that fail in this context means an assertion failing (AssertionFailedError, etc.) assert_assertion_fail is one alternative.... ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-08-04 12:53 Message: What about assert_raise([ExectedException1, expected_message1], ExpectedException2, ...) instead of creating new assertion? Uhmm... 'x < y' is clear rather than 'greater_than(x, y)' for me... We can use "<" instead of :<. :) BTW, I don't like '_operator' in 'assert_operator(x, "<", y)' form but I don't have good API idea. Is the name 'assert_fail' too generic, isn't it? Can we understand what should be failed easily? ---------------------------------------------------------------------- Comment By: Designing Patterns (designingpatts) Date: 2008-08-04 12:00 Message: Whichever name you think is best for assert_raise_message would be fine. I like assert_raise_message because it seems to follow the naming convention of assert_raise and since assert_raise_message does everything that assert_raise does but also checks the error message. I think that you're right about assert_not; now that assert_nil and assert_false exist, assert_not is not really necessary. assert_operator definitely is very flexible, but I find it clearer to use named alternatives for the common operations ( :< looks a bit weird to me, more like an emoticon than an operator :), whereas greater_than or gt makes immediate sense). I think that assert_fail is useful for users when they define assertions in their problem space and so should be visible. I'm not sure what you mean by defining it in the developer's test cases; are you referring to the unit tests for test-unit? If it's defined in there, then it will not be usable by or visible to programmers who want to test their own assertions in their own code. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-08-04 10:47 Message: assert_raise_message seems good but assert_exception_message may make sense. Is assert_not needed? assert_nil and assert_false exist. assert_greater_than family doesn't seem good name... Is assert_operator(x, :<, y) not good? assert_fail is not useful for users. It should be defined in developer's test cases. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=20851&group_id=5650 From noreply at rubyforge.org Sat Sep 27 15:19:35 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 27 Sep 2008 15:19:35 -0400 (EDT) Subject: [test-unit-tracker] [ test-unit-Feature Requests-20851 ] New Assertions Message-ID: <20080927191935.941C418581B8@rubyforge.org> Feature Requests item #20851, was opened at 2008-06-27 00:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=20851&group_id=5650 Category: None Group: None Status: Open Priority: 3 Submitted By: Designing Patterns (designingpatts) Assigned to: Nobody (None) Summary: New Assertions Initial Comment: I packaged some assertions that I found useful in a gem (http://assertions.rubyforge.org), and I think that they may be generally useful enough to be included with the standard Test::Unit. The assertions currently in the library are: assert_raise_message: Verifies that a specified error is raised and that it has a specified error message. assert_not: Verifies that the argument is false or nil asesrt_greater_than: Verifies that the first argument is greater than the second argument. Also assert_less_than, assert_greater_than_or_equal_to, assert_less_than_or_equal_to. I think that these are clearer than assert_operator. assert_fail: Verifies that a given block has an assertion that fails (useful for testing new assertions) ---------------------------------------------------------------------- >Comment By: Designing Patterns (designingpatts) Date: 2008-09-27 15:19 Message: Sorry that it took me so long to get back. I guess that passing an exception to assert_raise is okay, although I think that people will find assert_raise_message easier and clearer to use. assert_fail_assertion sounds great to me. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-09-12 23:20 Message: assert_raise_message: What about pass an exception instance to assert_raise? expected_exception = RuntimeError.new("some message") assert_raise(expected_exception) do raise "some message" end assert_compare: implemented in trunk. Thanks! assert_fail: What about assert_fail_assertion? ---------------------------------------------------------------------- Comment By: Designing Patterns (designingpatts) Date: 2008-08-21 17:38 Message: Given the choice between: assert_compare(a, "<", b) and assert_compare(a, "lt", b) I probably would use the former. I don't think that the latter has the brevity or clarity of assert_lt.... ---------------------------------------------------------------------- Comment By: Designing Patterns (designingpatts) Date: 2008-08-21 17:33 Message: assert_raise_message also could be named something like assert_raise_and_message or assert_raise_with_message... I think that passing in arrays to assert_raise makes the interface a bit messy... Regarding the example with assert_fail, I think that 'fail' should be clear enough from the context. As I mentioned before, assert_assertion_fail or assert_failed_assertion or some variant also could be used as a name, but I think that it might be overkill. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-08-09 21:48 Message: We can also specify just an exception class and message pair to assert_raise. It seems that assert_raise_message name feels checking just an exception message (an exception class is excluded). What about assert_compare(x, "<", y), assert_compare(x, "gt", y), assert_compare(x, "greater-than", y), ...? (or assert_comparison) I was thinking about the following situation: class TestDB < Test::Unit::TestCase def test_connection assert_fail do DB.connect("wrong user name", "wrong password") end end def assert_fail assert_raise(DB::ConnectionFailedError, &block) end end In the test case context, it seems that 'fail' means connection failure. ---------------------------------------------------------------------- Comment By: Designing Patterns (designingpatts) Date: 2008-08-04 12:29 Message: I guess that allowing Array arguments to assert_raise would be fine in order to implement verification of the error message... It's a bit weird, though, as I'm not sure that it makes sense to allow multiple error classes and messages to be asserted at the same time with assert_raise. Wouldn't a good test only assert a single error message? assert_raise_message also allows you to prefix a string to the failed assertion message, as many of the other assertion methods do. Instead of assert_operator, the method could be called assert_compare or assert_comparison. I don't have any hard figures with which to justify the assert_greater_than family of methods. My previous employer had them (and the assert_gt, assert_le, ... shorter aliases) The shorter aliases (assert_gt, assert_le, and assert_lt) probably will be very clear for some people, as some programming languages use gt instead of >, lt instead of <, le instead of <=, ... (Fortran, for example). I think that assert_fail is pretty clear, given that fail in this context means an assertion failing (AssertionFailedError, etc.) assert_assertion_fail is one alternative.... ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-08-03 23:53 Message: What about assert_raise([ExectedException1, expected_message1], ExpectedException2, ...) instead of creating new assertion? Uhmm... 'x < y' is clear rather than 'greater_than(x, y)' for me... We can use "<" instead of :<. :) BTW, I don't like '_operator' in 'assert_operator(x, "<", y)' form but I don't have good API idea. Is the name 'assert_fail' too generic, isn't it? Can we understand what should be failed easily? ---------------------------------------------------------------------- Comment By: Designing Patterns (designingpatts) Date: 2008-08-03 23:00 Message: Whichever name you think is best for assert_raise_message would be fine. I like assert_raise_message because it seems to follow the naming convention of assert_raise and since assert_raise_message does everything that assert_raise does but also checks the error message. I think that you're right about assert_not; now that assert_nil and assert_false exist, assert_not is not really necessary. assert_operator definitely is very flexible, but I find it clearer to use named alternatives for the common operations ( :< looks a bit weird to me, more like an emoticon than an operator :), whereas greater_than or gt makes immediate sense). I think that assert_fail is useful for users when they define assertions in their problem space and so should be visible. I'm not sure what you mean by defining it in the developer's test cases; are you referring to the unit tests for test-unit? If it's defined in there, then it will not be usable by or visible to programmers who want to test their own assertions in their own code. ---------------------------------------------------------------------- Comment By: Kouhei Sutou (kou) Date: 2008-08-03 21:47 Message: assert_raise_message seems good but assert_exception_message may make sense. Is assert_not needed? assert_nil and assert_false exist. assert_greater_than family doesn't seem good name... Is assert_operator(x, :<, y) not good? assert_fail is not useful for users. It should be defined in developer's test cases. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=21859&aid=20851&group_id=5650