New syntax for contract verifiers

[Yann Trevin]

A new branch was recently created in order to experiment a more
powerful/flexible syntax for contract verifiers. It mainly removes the
limitations due to the declaration of attributes in C# (for example no
possibility to pass object instances other than primitives)

The resulting new syntax declares the contract verifiers as read only
fields of test fixtures (rather than attributes of test fixtures). For
instance, here is how to declare a test fixture with 3 contract
verifiers for an hypothetical equatable and comparable custom
exception type named Foo (which probably makes no sense at all, but
it's just an example :))

public class FooTest
{
[ContractVerifier]
public readonly IContractVerifier ExceptionTests = new
VerifyExceptionContract<Foo>();

[ContractVerifier]
public readonly IContractVerifier EqualityTests = new
VerifyEqualityContract<Foo>()
{
EquivalenceClasses =
EquivalenceClassCollection.FromDistinctInstances( ... )
};

[ContractVerifier]
public readonly IContractVerifier ComparisonTests = new
VerifyComparisonContract<Foo>()
{
EquivalenceClasses =
EquivalenceClassCollection.FromDistinctInstances( ... )
};

[Test]
public void SomeOtherTest()
{
Assert.Fail("Oops!");
}
}

Any suggestion?

[Vladimir Okhotnikov]

I've been playing with the syntax described (not the actual code, I've
achieved the same syntax through a custom static TestSuite) and it seems
to cover most of what I can imagine to need... except for one thing.
When a contract involves interaction with, e.g. ORM framework (like
NHibernate) I'd like to be able to decorate the verifiers (or, better
yet, individual chunks of them, which used to be ContractVerifierPattern
subclasses) with custom setup/teardown code - initialize framework,
clear db data or recreate schema, initialize unit of work etc. Does this
sound right, or am I misusing the concept of contract verifiers?

[Jeff Brown]

Nifty.

Would it be good enough if the contract verifiers incorporated the [SetUp]
and [TearDown] behaviors at the fixture level?

[Vladimir Okhotnikov]

Good question. Not sure that it is the best option.

Suppose I have a contract which checks that entity supports basic CRUD
operations against the database - something like:
VerifyBasicPersistenceOperationsContract:
- Check that newly created entity is transient
- Check that entity can be saved to database (verifies mappings, db
schema, checks that an entity becomes non-transient and its ID is
populated with db primary key value etc)
- Check that entity can be loaded from database, by id
- Check that entity can be queried, by some property
- Check that changes in loaded entity can be saved to database
- Check that entity can be deleted from database (and the copy becomes
transient and ID is reset)

that kind of stuff. Now, ideally I would want to setup/teardown actions
to be performed before/after each individual check above. What you
propose is having something like:

public void TestOrder {
[ContractVerifier] private readonly IContractVerifier
persistenceOpsVerifier = new VerifyBasicPersistenceOperationsContract();

[SetUp]
public void Init() {
EnsureOrmFrameworkInitialized();
PurgeAllDataFromDb();
StartUnitOfWork();
}

[TearDown]
public void Terminate() {
EndUnitOfWork();
PurgeAllDataFromDb();
}

Which have a couple of drawbacks imho. First, I will have to introduce a
base TestFixture class with these setup/teardown methods (and probably
the verifier as well), and inherit TestOrder from it, to avoid code
duplication in each TestEntity class. (Or I may use generic fixture with
[Row] maybe). This is not very bad, I just wonder does it still conform
to mixin approach. Also, maybe the setup/teardown logic (the intent at
least) should be better encapsulated inside the contract itself (and
implementation supplied like new
VerifyBasicPersistenceOperationsContract<NHibernateTestContextProvider>)
so that contracts can be more easily reused between projects, perhaps
those using different ORMs?

Second, I might also wish to throw in the non-persistent contract
verifier in the mix (like equality one). I would hardly be glad to have
the database context going on and off on those checks. This might be
resolved by something like:

public abstract class BaseEntityFixture { new EqualityContractVerifier(); }
public abstract class BasePersistentEntityFixture : BaseEntityFixture {
new PeristentContractVerifier(); [SetUp]...}

if verifiers in a base fixture would not call the setup/teardown from
derived ones... but is it the best way?

[Jeff Brown]

Why not use nested fixtures?

public class TestOrder
{
// some tests...

public class Persistence : BaseEntityPersistenceTest<Order>
{
}
}

Jeff.

[Vladimir Okhotnikov]

Indeed. Yes, this will likely suffice.