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 ;-)
Unfortunately this is very much a case where I DO have to eat your sandwich. I
mean really, who is the example for? --Other people.
| > 2. Detracts from the code itself.
|
| Why?
Well one isn't a big deal. But a few or more, the code itself begins to get a
bit lost.
| > 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.
Sure, but it doesn't _look_ like a real example. I may be wrong but it seems
to me that the format of these will be structured for testing rather then
looking at them to understand their general usage. In other words testing and
examples can differ. For instance, you may have a method that is only meant
for use in a particular context. An example would provide a mock context, but
a test might not have the resources available to build an actual context.
| > 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.
Okay, that helps _a lot_. But b/c of this, I suspect that the above notation
will get little play. It won't be enough for solid testing, and it will be
too little for effective examples in RDoc. Of course, that's just my hunch, I
may be wrong.
| > 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.
So the test suites do not use example { ... }. Okay.
| > 6. I would prefer to see improvement in test
| > "comprehension" over other changes.
|
| Not sure what you mean... care to elaborate?
Not that this is an easy thing to do mind you, but what I mean is making the
test system more intelligent. Might the test suite actually parse the code
itself? Look for potential errors in a deeper way then the Ruby interpretor?
Perhaps a method probe, even if it's not perfect, might be useful? I think I
read something about Mock object builder coming? Stuff like that. That's part
of the reason I was suggesting that a test (at least most tests) can be a
subclass of the actual class it's testing, hence being on the "inside" of
their objective. Perhaps that's not really useful, I'm just pushing in the
direction of the test "knowing" more about what it is actually trying to do
and therefore being able to do more of it on it's own --that's essentially
what I mean by comprehension.
| [snip my example]
|
| 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.
Right, but my example does have an interesting potential advantage. The test
method is closer to --nearly inside of, the method it is testing. One could
do this for instance:
class Testing::Adder < Adder
def add(*args)
assert("add failure") { _equal 2, super(1, 1) }
super(*args)
end
end
Then have a moster control to have test classes sub in for regular classes,
and you could run the test suite through a real case scenario, while testing
at the same time. Of course not situations would be suitabel for this. But
like I said, I'm just pushing the limits in a general direction here to what
might come up.
It we got further into AOP-land there are other interesting things one might
do (like check local vars in mid execution). But since I (and partners) are
not finished our "AOP for Ruby" project yet, I hesitate to speculate further
at this time.
I'm not sure what kind of time track you're shooting for, so maybe this kind
of stuff is really the domain of _consideration_ for version 3, not 2.
T.
