Eu pessoalmente hesitaria em injetar nulos. Na verdade, sempre que eu insiro dependências em um construtor, uma das primeiras coisas que faço é gerar um ArgumentNullException se essas injeções forem nulas. Dessa forma, posso usá-los com segurança dentro da minha turma, sem dezenas de verificações de nulos espalhados. Aqui está um padrão muito comum. Observe o uso de readonly para garantir que as dependências definidas no construtor não possam ser definidas como null (ou qualquer outra coisa) posteriormente:

class Car
{
   private readonly ICarRadio _carRadio;
   private readonly IMotor _motor;

   public Car(ICarRadio carRadio, IMotor motor)
   {
      if (carRadio == null)
         throw new ArgumentNullException(nameof(carRadio));

      if (motor == null)
         throw new ArgumentNullException(nameof(motor));

      _carRadio = carRadio;
      _motor = motor;
   }
}

Com o acima, eu poderia talvez ter um teste de unidade ou dois, onde injetar nulos, apenas para garantir que minhas verificações de nulos funcionem conforme o esperado.

Dito isto, isso se torna um problema, uma vez que você faz duas coisas:

1. Programa para interfaces em vez de classes.
2. Use um framework de simulação (como o Moq for C #) para injetar dependências com mock, em vez de nulos.

Então, para o seu exemplo, você teria:

interface ICarRadio
{
   bool Tune(float frequency);
}

interface Motor
{
   bool SetSpeed(float speed);
}

...
var car = new Car(new Moq<ICarRadio>().Object, new Moq<IMotor>().Object);

Mais detalhes sobre o uso do Moq podem ser encontrados aqui .

Claro, se você quiser entendê-lo sem zombar primeiro, você ainda pode fazê-lo, contanto que esteja usando interfaces. Basta criar um CarRadio e um Motor fictícios como segue e injetá-los:

class DummyCarRadio : ICarRadio
{
   ...
}
class DummyMotor : IMotor
{
   ...
}

...
var car = new Car(new DummyCarRadio(), new DummyMotor())

Não está tudo bem, é uma técnica bem conhecida de interrupção de dependências para colocar o código legado em um equipamento de teste. (Veja "Trabalhando Efetivamente com o Código Legado", de Michael Feathers.)

Cheira? Bem ...

O teste não tem cheiro. O teste está fazendo o seu trabalho. Ele está declarando que "este objeto pode ser nulo e o código em teste ainda funciona corretamente".

O cheiro está na implementação. Ao declarar um argumento de construtor, você está declarando que "essa classe precisa dessa coisa para funcionar adequadamente". Obviamente, isso é falso. Qualquer coisa falsa é um pouco malcheiroso.

Vamos dar um passo atrás para os primeiros princípios.

A unit test tests some aspect of a single class.

Haverá, no entanto, construtores ou métodos que tomam outras classes como parâmetros. O modo como você lida com isso varia de caso para caso, mas a configuração deve ser mínima, uma vez que é tangencial ao objetivo. Pode haver cenários em que a passagem de um parâmetro NULL seja perfeitamente válida - como um carro sem rádio.

Estou assumindo aqui que estamos apenas testando a linha de corrida para começar (para continuar o tema do carro), mas você pode também querer passar NULL para outros parâmetros para verificar se qualquer código defensivo e mecanismos de entrega de exceção estão funcionando conforme necessário.

Até aí tudo bem. No entanto, e se NULL não for um valor válido. Bem, aqui você está no mundo obscuro de Mocks, stubs, dummies e fakes .

Se tudo isso parece um pouco demais, você já está usando um boneco passando NULL no construtor Car, já que é um valor que potencialmente não será usado.

O que deve ficar claro rapidamente, é que você está potencialmente atirando em seu código com muito tratamento NULL. Se você substituir os parâmetros de classe por interfaces, também abrirá o caminho para o escárnio e DI, etc., o que os tornará mais simples de lidar.

Ao analisar seu design, sugiro que um Car seja composto por um conjunto de Features . Um recurso talvez um CarRadio ou EntertainmentSystem , que pode consistir em coisas como CarRadio , DvdPlayer etc.

Então, no mínimo, você teria que construir um Car com um conjunto de Features . EntertainmentSystem e CarRadio seriam implementadores da interface (Java, C # etc) do public [I|i]nterface Feature e isso seria uma instância do padrão de design Composite.

Portanto, você sempre construiria um Car com Features e um teste de unidade nunca instanciaria um Car sem nenhum Features . Embora você possa considerar zombar de um BasicTestCarFeatureSet que tenha um conjunto mínimo de funcionalidade necessário para seu teste mais básico.

Apenas alguns pensamentos.

John