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.

<:((><