Molte persone consigliano di codificare le interfacce e di evitare la statica per la testabilità.
Le interfacce non sono solo testabilità, a volte sono un requisito. Ma a volte introduciamo nuove interfacce nell'applicazione solo per testabilità.
Se il type mocking frameworks ci aiuta a isolare i tipi dipendenti, allora perché dovremmo usare le interfacce solo per motivi di testabilità? Inoltre, perché dovremmo evitare membri statici?
Non devi introdurre una nuova interfaccia se sei sicuro al 100% che la classe che stai deridendo non avrà un comportamento polimorfo in futuro.
Di 'se stai prendendo in giro una classe DatabaseHelper che ti aiuta ad accedere ai dati da SQL Server, e sei sicuro che tu (o i tuoi sviluppatori di successo) sicuramente non permetterai di supportare alcun Database aggiuntivo (MySql, Oracle, ecc.) In futuro, puoi prendere in giro direttamente DatabaseHelper senza introdurre una nuova interfaccia.
Tuttavia, la maggior parte delle volte non puoi prevedere il futuro, quindi è meglio che tu introduca un'interfaccia per l'estensione futura.
non usiamo l'interfaccia solo per motivi di testabilità. È il perseguimento della testabilità che ci costringe a scrivere codice estensibile / gestibile introducendo una nuova interfaccia.
Also, why should we avoid static members
I membri statici sono la variabile di stato globale nella sua essenza. Le unità di codice che condividono / accedono allo stato globale sono in genere altamente accoppiate, il che rappresenta una minaccia per la gestibilità, la sicurezza del thread e il test delle unità isolate, ecc.
If type mocking frameworks help us to isolate dependent types, then why should we use interfaces just for the sake of testability? Also, why should we avoid static members?
Penso che tu abbia risposto alla tua stessa domanda qui. Le interfacce che rappresentano un componente testabile migliorano la testabilità del componente e solo con questa misura è preferibile ai componenti con funzionalità o business logic che hanno una tipizzazione statica. Statica e singleton ingiustificati sono molto più difficili da gestire con la maggior parte delle strutture di derisione. Ciò rende i test unitari più complicati.
Oltre ai vantaggi di testabilità, un componente con un'interfaccia diminuisce l'accoppiamento tra i componenti. I componenti sono modulari e coesivi . Il design basato sui componenti richiede l'interfaccia come contratto tra il comportamento definito e l'attore. Questo aspetto di un componente li rende più sostituibili . link
Questi tempi in cui vengono introdotti solo per testabilità non sono corretti.
Come altri hanno già detto, la programmazione contro un'interfaccia diminuisce l'accoppiamento tra i componenti e consente al tuo codice di essere facilmente estendibile in futuro.
Questo a sua volta consente di testare più facilmente i componenti in modo isolato.
Anche se l'introduzione di un'interfaccia potrebbe darti un po 'più di lavoro ora, è una buona base su cui costruire il tuo software.
Generalmente non creo una nuova interfaccia ogni volta che faccio una finta. Sinceramente sento che non fornisce abbastanza valore ed è solo un altro file da gestire. Una volta che il codice della logica aziendale dell'applicazione mi porta a implementazioni multiple, posso estrarre un'interfaccia. Potrei anche creare una classe astratta o utilizzare un altro modello di delega per implementarlo. Come accennato altrove, il refactoring dell'interfaccia di estrazione è una semplice sequenza di tasti e ci consente di creare quell'interfaccia appena in tempo.
Per quanto riguarda la statistica, hanno la tendenza a incoraggiare lo stato globale, che può essere problematico (le variabili globali orientate agli oggetti sono ancora variabili globali). Inoltre, spesso li vedo usati come metodi di creazione chiamati dai loro collaboratori invece di usare il fai-da-te che li rende difficili da falsificare.
Grazie!
Brandon
Leggi altre domande sui tag tdd unit-testing design-patterns