Unas cuantas opciones para refactorizar un método a la hora de testearlo

Sample.cs

// Situación inicial
public class OrderStatsCalculator
{
  	// Inyectado por constructor. En todos los casos lo hago igual.
	private IOrderRepository repository;

	// Esto se puede testear con un mock/stub/fake/etc. que inyectes por 
	// el constructor
	public int Calculate()
	{
		var orders = repository.GetOrders();
		return orders.Sum(x => x.Total);
	}
}

// Opción 1: Extract and override
public class OrderStatsCalculator
{
	public int Calculate()
	{
		var orders = GetOrders();
		return orders.Sum(x => x.Total);
	}

	// En los tests puedo redefinir este método y devolver los orders 
	// que quiera. Me "ahorro" el mock (aunque algo tendré que inyectar
	// por el constructor, pero podría ser incluso un null).
	public virtual IEnumerable<Order> GetOrders()
	{
		return repository.GetOrders();
	}
}


// Opción 2: Separando la lógica de la interacción
public class OrderStatsCalculator
{
	public int Calculate()
	{
		var orders = repository.GetOrders();
		return Calculate(orders.ToArray());
	}
	
	// En los tests testeo este método, que es el que tiene lógica, 
	// y paso del otro que sólo coordina. Eso hace que el test sea 
	// más sencillo de escribir porque se convierte en una función
	// pura (sin efectos colaterales) en la que además la salida 
	// sólo depende de la entrada (no hay valores devueltos por 
	// otros métodos, ni otros objetos, ni nada).
	// Este tipo de función suele ser el caso ideal para testear.
	public int Calculate(Order[] orders)
	{
		return orders.Sum(x => x.Total);
	}
}