Interfaccia tra codice dell'applicazione e test di unità

Penso che testare i metodi pubblici sia sufficiente la maggior parte del tempo.

Se hai una grande quantità di complessità nei tuoi metodi privati, allora considera di metterli in un'altra classe come metodi pubblici e usarli come chiamate private a quei metodi nella tua classe originale. In questo modo puoi garantire che entrambi i metodi nelle classi di utilità e originali funzionino correttamente.

Affidarsi in maniera massiccia ai metodi privati è un aspetto da considerare in merito alle design desicions.

Alla domanda 1: dipende da In genere, si inizia con i test unitari per i metodi pubblici. A volte si incontra un metodo che si desidera mantenere privato in A, ma si ritiene che sia opportuno testarlo anche separatamente. In questo caso, dovresti rendere pubblico m o rendere la classe di test TestA una classe friend di A . Ma attenzione, aggiungere un test unitario per testare m rende un po 'più difficile cambiare la firma o il comportamento di m in seguito; se vuoi mantenere un "dettaglio di implementazione" di A, potrebbe essere meglio non aggiungere un test di unità diretto.

Domanda 2: l'aggregazione composita (C ++ build-in) non funziona bene quando si tratta di simulare un'istanza. Infatti, poiché la costruzione di B avviene implicitamente nel costruttore di A, non hai la possibilità di iniettare la dipendenza dall'esterno. Se questo è un problema dipende dal modo in cui vuoi testare A: se pensi che abbia più senso testare A da solo, con una simulazione di B invece di B, meglio usare una semplice associazione. Se pensi di poter scrivere tutti i test unitari necessari per A senza prendere in giro B, allora un composito sarà probabilmente ok.

Domanda 3: cambiare un'API per rendere le cose più testabili è comune finché non si dispone di molto codice fino a quel momento basato su tale API. Quando si esegue TDD, non è necessario modificare l'API in un secondo momento per rendere le cose più testabili, inizialmente si inizia con un'API progettata per la testabilità. Se vuoi cambiare un'API in seguito per rendere le cose più testabili, potresti incontrare dei problemi, è vero. Quindi andrei con la prima o la seconda delle alternative che hai descritto purché tu possa cambiare la tua API senza dolore e usare qualcosa come la tua terza alternativa (nota: funziona anche senza il modello singleton) solo come ultima risorsa se devo non modificare l'API in nessun caso.

Riguardo alle tue preoccupazioni che potresti "sbagliare": ogni grande motore o macchina ha aperture di manutenzione, quindi IMHO la necessità di aggiungere qualcosa del genere al software non è troppo sorprendente.

Dovresti cercare Iniezione delle dipendenze e Inversione del controllo. Misko Hevery spiega molto sul suo blog. DI e IoC sono effettivamente un modello di progettazione per creare codice facile da testare e simulare.

Domanda 1: No, non rendere pubblici i metodi privati per testarli. Se il metodo è sufficientemente complesso, è possibile creare una classe collaboratore che contenga solo quel metodo e iniettarla (passare al costruttore) nell'altra classe. ¹

Domanda 2: chi costruisce A in questo caso? Se si ha una classe factory / builder che costruisce A, non vi è alcun danno nel passare il collaboratore B nel costruttore. Se A è in un pacchetto / spazio dei nomi separato dal codice che lo utilizza, puoi addirittura rendere privato il pacchetto del costruttore e renderlo tale che factory / builder è l'unica classe in grado di costruirlo.

Domanda 3: Ho risposto a questa domanda alla domanda 2. Alcune note aggiuntive però:

• L'uso di un modello di builder / factory ti consente di fare l'iniezione delle dipendenze quanto vuoi, senza doverti preoccupare di rendere il codice difficile da usare con la tua classe.
• Separa tempo di costruzione dell'oggetto da tempo di utilizzo dell'oggetto , il che significa che il codice che utilizza l'API può essere più semplice.

¹ _{Questa è la risposta C # / Java - C ++ potrebbe avere funzionalità extra che facilitano questo}

Come risposta ai tuoi commenti:

Ciò che intendevo era che il tuo codice di produzione sarebbe stato modificato (per favore perdona il mio pseudo-C ++):

void MyClass::MyUseOfA()
{
  A* a = new A();
  a->SomeMethod();
}

A::A()
{
  m_b = new B();
}

a:

void MyClass::MyUseOfA()
{
  A* a = AFactory.NewA();
  a->SomeMethod();
}

A* AFactory::NewA()
{
  // Construct dependencies
  B* b = new B();
  return new A(b);
}

A::A(B* b)
{
  m_b = b;
}

Quindi il test può essere:

void MyTest::TestA()
{
  MockB* b = new MockB();
  b->SetSomethingInteresting(somethingInteresting);

  A* a = new A(b);

  a->DoSomethingInteresting();

  b->DidSomethingInterestingHappen();
}

In questo modo, non è necessario passare di fabbrica, il codice che chiama A non ha bisogno di sapere come costruire A, e il test può costruire A su misura per consentire il test del comportamento.

Nel tuo altro commento hai chiesto delle dipendenze nidificate. Quindi, ad esempio, se le tue dipendenze erano:

A -> C -> D -> B

La prima domanda da porsi è se A usa C e D. Se non lo sono, perché sono inclusi in A? Supponendo che vengano utilizzati, allora forse è necessario passare in C nella tua fabbrica e fare in modo che il tuo test costruisca un MockC che restituisca un MockB, permettendoti di testare tutte le possibili interazioni.

Se questo sta cominciando a complicarsi, potrebbe essere un segno che il tuo design è forse accoppiato troppo strettamente. Se è possibile allentare l'accoppiamento e mantenere alta la coesione, questo tipo di DI diventa più semplice da implementare.