c# - Is it wrong to use Assert.That (rather than Assume.That) with a [Theory]? -

interface ipoint {     int x { get; }     int y { get; } }  static bool coincideswith(this ipoint self, ipoint other); // implementation unknown 

i want write nunit test verifies assumption meaning of coincideswith:

self.coincideswith(other) ⇔ (self.x = other.x) ∧ (self.y = other.y)

the following succinct test i've been able come far:

[theory] void coincideswith_iff_coordinatesareequal(ipoint self, ipoint other) {     bool coordinatesareequal = (self.x == other.x && self.y == other.y);     assert.that(self.coincideswith(other) == coordinatesareequal); } 

my questions, in descending order of importance, are:

1. with [theory], considered wrong, or bad style, use assert.that instead of assume.that? (the documentation seems suggest latter should used in conjunction [theory].)
2. is case indeed more suitable [theory] rather [test]?

after more thought, i've come conclusion there nothing wrong above solution.

is case indeed more suitable [theory] rather [test]?

if implementation coincideswith method available inspection (e.g. source code), or @ least well-documented, there no need make assumptions — need know. in case, [test] — or, xunit.net calls tests, [fact] — seem more appropriate.

but since have no access implementation coincideswith, , documentation insufficient, need make assumption, or [theory], general working of method.

with [theory], considered wrong, or bad style, use assert.that instead of assume.that?

no. it's tool used, , neither less nor more appropriate assert.that.

in context of [theory], assume.that seem right means of putting additional constraints on supplied [datapoints], while verifying actual assumption (using datapoints make past assume.that) left assert.that.

an example can illustrate this. let's try write test assumption:

given integer a , odd integer b, product a * b even.

testing if a * b makes sense once preconditions met. if a not integer, or b not odd integer, test should neither succeed nor fail; should inconclusive. , that's assume.that helps achieve. actual test, however, left assert.that:

[theory] void givenanevenintegerandanoddinteger_productisaneveninteger(int a, int b) {     assume.that(a.iseven());     assume.that(b.isodd());     // note: type system ensures `a` , `b` integers.     int product = * b;     assert.that(product.iseven());     // note: theory doesn't require `product` integer,     // if type system didn't assert this, not test it. }  [datapoints] int[] integers = { 1, 2, 3, 4, 5, 6, 7 };  static bool iseven(this int integer) { … } static bool isodd(this int integer) { … }