On Oct 14, 2004, at 23:42, trans. (T. Onoma) wrote: > On Wednesday 13 October 2004 09:19 pm, Nathaniel Talbott wrote: > | Well, the current plan is to let you to do something like this: > | > | class Adder > | include Testing > | > | # Adds two numbers > | example { assert_equal(2, Adder.new.add(1, 1)) } > | def add(a, b) > | a + b > | end > | end > > Well, I say, I like the general idea of sub('::', '/') and all --making > testing a dialect, if you will. But I can't say that I would want to > use the > above b/c > > 1. Adds a performance hit (albeit small). Yup. It's miniscule, and I just don't care. If you do, you don't have to eat my sandwich ;-) > 2. Detracts from the code itself. Why? > 3. Not really an example, but a test. But many tests are great examples, and I want to leverage that. And all examples should be tests, because then you're sure they actually work. > 4. There can be tens to hundreds of tests. I should clarify: the bulk of tests will be elsewhere. This is specifically for basic examples of tests, not full regression suites. > 5. How does it know that example goes to that method, > other then occurring before it. That's exactly how it knows. Any examples before a given method would be assumed to correspond to that method, just as any comments before a method are assumed (by RDoc) to correspond to that method. > 6. I would prefer to see improvement in test > "comprehension" over other changes. Not sure what you mean... care to elaborate? > To offer some contrast, here's is a sample concept inspired a bit by > my AOP > work. > > class Adder > # Adds two numbers > def add(a, b) > a + b > end > end > > class Testing::Adder < Adder > def add > assert("add failure") { _equal 2, super(1, 1) } > end > end > > Notice I did not have to specify 'include Testing'. It may be able to > be can > be automatically included "behind the scenes" simply be using the > Testing:: > namespace. > > It's not dialectic, but it does integrate better while still allowing > good > SOC. I guess I don't see any advantages of this over: class AdderTest < Test::Unit::TestCase def test_add assert_equal(2, Adder.new.add(1, 1)) end end Besides the fact that the latter seems to be much more intention revealing. Or perhaps even better: suite "Adder" do test :add do assert_equal(2, Adder.new.add(1, 1)) end end Which is probably how you'd do it in test/unit2. Nathaniel Terralien, Inc. <:((><