Mikkel Krøigård <[EMAIL PROTECTED]> writes:

>> My idea is that we should have unit tests which target one thing only:
>> The tests using BinaryOperatorTestCase targets coercion between plain
>> integers, field elements, and Share objects. The tests in
>> test_thresholds.py target different thresholds.
> You mean the multiplication test for example should only target
> coercion? Isn't that a bit strange?

No -- we should have different tests for different facets of the
software, and one is coercion. That is why I think it is okay for the
tests to use the numbers 1234 and 5677 in all tests.

That is also why I often made pseudo-sharings where I give the players
the shares (x + runtime.id) -- when the goal of the test is to test
something else than shamir.share, then we should ideally try not to
call that function.

There is a whole story about mockup objects which we've not yet
started using. See for example this tutorial:

  http://labix.org/mocker#head-0c676f1e71710302abe7e1a5bb4fdd0b944aca8b

> We have the share-share test for example, that's not really about
> coercion is it.

It tests the case where there should be no coercion... :-)

> I am not sure I agree with that way of doing it anyway. It seems to
> me that the thresholds test would have to test everything anyway, so
> to me it makes more sense that everything else can be tested with
> different numbers of players and different thresholds.

Yeah, I agree that it would be nice to automatically test everything
with all sort of combinations of thresholds. But it must be done in a
way that ensures that we can pinpoint the errors when we find them. It
is no good if a test case fails and you cannot tell why.

I'm not saying that it would be bad to rewrite the tests to ensure
that they are independent of the number of players and threshold --
our tests today are already quite good at separating concerns.

-- 
Martin Geisler
_______________________________________________
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

Reply via email to