Test e accoppiamenti dell'unità

Question

Test e accoppiamenti dell'unità

#1 da (4 voti)
#2 da (0 voti)

4

Come sviluppatore dovrei cercare un accoppiamento basso tra le classi.

Ma l'accoppiamento basso non significa "nessun accoppiamento", quindi a volte devo consentire una certa flessibilità del codice e usare "nuovo" all'interno di un modello di dominio. (Sono sicuro che tutti lo fanno nel vero codice di produzione)

Se uso "nuovo" all'interno di un metodo per creare un oggetto e devo testare questo metodo, ho riscontrato un problema. Perché non posso prendere in giro gli oggetti non posso testare il metodo in isolamento. So che posso usare l'iniezione di dipendenza o posso inviare oggetti come parametri ma non sto parlando di questi casi chiari.

Questo è accettabile nella pratica?
Esiste un modo migliore? (Non posso sempre iniettare)
Si tratta di un test unitario o di integrazione?

Esempio PHP:

class Car {
   protected $objDoor;
   public function createComponents() {
       $this->objDoor = new Door();
   }
}

unit-testing coupling

posta danidacar 30.07.2013 - 09:16

fonte

2 risposte

0

  > Is there a better way? (I can't always inject)

Non migliore ma più semplice ed equivalente:

Se non vuoi iniettare un metodo / classe factory per creare un nuovo elemento domain-child puoi implementare un metodo factory virtuale protetto locale

public class MyClassUnderTest {
   virtual protected MyObjectType createMyObjectType() {return new MyObjectType();}
}

e usa questo metodo factory invece di chiamare new MyObjectType() direttamente.

Nel test erediti da MyClassUnderTest e sovrascrivi createMyObjectType() con un codice di simulazione o chiedi a mocking-framework di restituire qualche oggetto secondario speciale se viene chiamato createMyObjectType ().

risposta data 30.07.2013 - 18:07

fonte

Leggi altre domande sui tag unit-testing coupling

Ricerca testuale: problema con i big data Fornire sia interfacce RESTful che Java?

score 4 · Accepted Answer

Iniezione di dipendenza

Penso che sia strongmente dipendente dall'oggetto che stai creando. Se crei un oggetto che poi restituisci, è in qualche modo parte delle specifiche del metodo. In quel caso sarebbe praticamente possibile fare un test unitario.

Come faresti un test unitario per la classe in questione (quella che usi new on), questo non dovrebbe essere il problema principale. Ma se crei un oggetto e fai qualcosa con quell'oggetto (produci effetti collaterali), dovresti usare l'iniezione. Questo è ancora più vero se ottieni tutti i parametri per la chiamata del costruttore come parametri del tuo metodo. Basta creare l'oggetto prima di chiamare il metodo e dare invece il riferimento.

Ma ovviamente ciò implicherebbe che il metodo con cui viene creato l'oggetto, stia facendo ora la stessa cosa.

Detto questo, avrai bisogno di una sorta di meccanismo centrale che gestisca l'iniezione della dipendenza. Symfony fornisce un componente Dependency Injection che gestisce quella roba.

Copertura del codice

È importante avere una copertura del codice. Dipende strongmente dal tuo progetto quanto bene possa essere fatto. Quando possibile, dovrebbero essere scritti test unitari. Oltre a questo, dovresti usare test funzionali che testano una certa funzione (e quindi l'interazione delle classi necessarie). Tutto sommato che dovrebbe soddisfare le tue necessità.