Consentitemi di prefigurare questa domanda dicendo che ho bisogno di test delle unità. L'ho dolorosamente capito. Devi farlo per garantire che le future modifiche non influiscano negativamente sull'applicazione in modi che non ti aspetti. È inoltre buona norma utilizzare una metodologia basata sui test per garantire che le modifiche correnti funzionino come previsto, fornendo al contempo una solida base di test per l'aggiunta di casi limite (bug) in un secondo momento. Capisco anche che il test è un requisito per qualsiasi azienda che intende o è soggetta a un audit IT. Infine, se il tuo codice è testabile, è probabile che sia stato scritto utilizzando solidi principi di progettazione.
Il dilemma che ho è quello di codificare un'interfaccia allo scopo di sostenere da solo il test delle unità, sembra una complessità forzata.
Prendete il caso in cui avete un'applicazione di database che non ha il requisito di essere indipendente dal database. Hai già codificato un DAL che comunica con quel database e BL che usa quel DAL per la persistenza. Sono in atto test di integrazione con l'architettura corrente che utilizza un database di sviluppo per i dati di test.
Per supportare la copertura del codice al 100% sui test unitari ora è necessario introdurre interfacce sia per il DAL che per il BL, avere implementazioni concrete di tali interfacce e utilizzare la dipendenza o l'iniezione del costruttore per utilizzare tali interfacce in base al contesto del tempo di esecuzione.
Questo non introduce una complessità forzata? Una domanda secondaria, immagino, dov'è la linea tracciata tra unità e test di integrazione in questi casi? È certamente possibile che il modello di dati possa cambiare e che si desideri test di integrazione in aggiunta al test delle unità, poiché è chiaro che i test delle unità avranno esito positivo laddove il test di integrazione può fallire in quel caso.