Unit testing methods which depend on other member of the interface being called

Question

Let's say I have an interface called IOrderContainer :

public interface IOrderContainer
{
    ReadOnlyCollection<Order> Orders { get; }
    void AddOrder(Order order);
    void RemoveOrder(Order order);
    Order GetOrderById(int orderId);
}

The implementation keeps a private collection of orders, which is exposed by a public read-only collection Orders

AddOrder and RemoveOrder modifies the private collection.

How would I unit test GetOrderById and RemoveOrder methods, if there's no public members on the interface to initialize the private orders collection?

The obvious way is to call AddOrder a bunch of times to populate the private collection, but I feel that it violates the definition of a unit test, because to test RemoveOrder / GetOrderById , we depend on another "unit" - AddOrder .

Should I create two constructors? One parameterless constructor and another one that takes in the collection and assigns it to the private collection.

Answer 1

A unit test checks an implementation (or better: its behaviour), not an interface. So it's perfectly OK to have an implementing class with multiple constructors, one having a parameter used to initialise the collection.

An alternative would be not to populate the collection and check if eg AddOrder behaves correctly: whether the order is added to whatever the previous content of the collection was. But even then you are still testing two 'units' (the 'Addorder' method and the getter for the collection).