Il test delle unità può coinvolgere un numero di librerie e dipendenze diverse dall'applicazione associata.
Pensando a un'applicazione che ho scritto di recente come proof of concept (Java) - una semplice app CRUD con test unitari contro un database in memoria.
WebApp | Unit Test
-------+----------
| JUnit
| Mockito
Tomcat | Jetty
Mysql | HSqldb
Quindi, nell'app Web, sto solo collegando Tomcat e Mysql. All'interno del test delle unità ho usato JUnit, Mockito, Jetty e HSqldb. Quindi non è solo una compilazione condizionale da provare a rimuovere, ma sono anche i vari framework di testing che non si vogliono collegare con l'applicazione principale. Mockito, Junit, Jetty e HSqldb non hanno alcun posto nell'applicazione di produzione: perché includerli come parte del collegamento e della distribuzione per questo?
Quando si lavora con Maven (di nuovo Java), la struttura della directory assomiglia a:
my-app
|-- pom.xml
'-- src
|-- main
| '-- java
| | '-- com
| | '-- mycompany
| | '-- app
| | '-- App.java
| 'resources
|
'-- test
'-- java
| '-- com
| '-- mycompany
| '-- app
| '-- AppTest.java
'resources
Le directory delle risorse sono quelle in cui si hanno le informazioni di iniezione della dipendenza in modo che quando il test viene eseguito, vengono utilizzate le risorse di test (consentendo di avere la connessione al database in memoria anziché alla produzione).
Questa struttura impedisce anche che AppTest venga compilato con l'applicazione principale. O una qualsiasi delle risorse per i test da compilare. Il processo di compilazione non fa nemmeno vedere la directory test . Pertanto, il codice testato è identico al codice distribuito.
L'ultimo bit è la chiave: il codice testato è lo stesso del codice distribuito. Ricordo i miei giorni al college con un codice C che ne aveva disseminato #ifdef DEBUG , e occasionalmente c'era del codice che aveva un effetto collaterale. Prenderò il debug e non funzionerebbe. Fai il debug su, va bene. Lo stesso problema esiste con la compilazione condizionale. può esistere anche con il test (se inizi a armeggiare nel budello del modulo mentre lo collaudi, ma diventa più difficile fare cattive pratiche perché è più facile farlo nel modo giusto.
L'altro bit è anche se questo codice non è un codice che è possibile richiamare facilmente: testare codice di qualsiasi tipo nel codice distribuito significa che un utente malintenzionato potrebbe essere in grado di trovare quella funzione da invocare o il punto di ingresso da chiamare che ora espone qualcosa che non dovresti permettere agli utenti di ottenere.