Gallio v3.0.6 is closed to be released. Among the numerous new features and fixes, mostly brought by Jeff and Graham, we have added a new contract verifier for the collection types.
The collection contract verifies that your implementation of the generic interface ICollection<T> behaves correctly. In particular, the contract verifier tests the addition and the deletion of items, but also the consistency of the Count and the ReadOnly properties.
The syntax for declaring a collection contract verifier is very similar to the other contracts:
The collection contract verifies that your implementation of the generic interface ICollection<T> behaves correctly. In particular, the contract verifier tests the addition and the deletion of items, but also the consistency of the Count and the ReadOnly properties.
The syntax for declaring a collection contract verifier is very similar to the other contracts:
[VerifyContract]
public readonly IContract CollectionTests = new CollectionContract<TCollection, TItem>
{
// Some Options...
};
You may specify some optional properties to make the contract verifier better fit your specific needs. For instance, setting AcceptEqualItems to true indicates that the collection is expected to accept duplicate items (object equality). You can also provide a custom default instance of the collection by feeding GetDefaultInstance (by default the default constructor is invoked).
To completely test a collection type is a particular painful task. The new collection contract verifier is then probably a nice time saver. However, the verifier expects your collection to have a strictly regular behavior, such as List<T>. It will probably not be suitable for a custom collection which treats addition or deletion of items with a different logic. We could have made the verifier even more flexible with additional options, but at a certain point, it is probably better to write manually the unit tests with ones own little fingers.
To completely test a collection type is a particular painful task. The new collection contract verifier is then probably a nice time saver. However, the verifier expects your collection to have a strictly regular behavior, such as List<T>. It will probably not be suitable for a custom collection which treats addition or deletion of items with a different logic. We could have made the verifier even more flexible with additional options, but at a certain point, it is probably better to write manually the unit tests with ones own little fingers.
