Finora ho usato per scrivere interfacce per quelle classi che voglio simulare / falsificare. Il motivo è che quelle classi non hanno alcun metodo virtuale per sovrascrivere. Ma recentemente ho capito che potevo usare anche metodi virtuali.
Quando dovrei usare metodi virtuali piuttosto che interfacce?
Dovrei persino rendere la maggior parte dei metodi virtuali per rendere più facile il finto in futuro?
Come potrebbero aiutare i metodi virtuali? L'idea di deridere è che estrai una classe completamente dalla tua applicazione e inserisci una classe mocked completamente diversa, con l'unica cosa in comune che entrambi implementano la stessa interfaccia. L'ereditarietà non entra affatto nel gioco.
I metodi virtuali e la loro sovrascrittura non è un buon modo per creare mock rispetto alle interfacce.
Perché dovrai fare riferimento alla classe sottostante per creare la tua simulazione. Quindi i tuoi test dipenderanno da un riferimento a quella particolare libreria
E anche perché esponi i metodi che altrimenti potresti non voler.
Se hai bisogno di rendere virtuali i tuoi metodi per testarli (ad esempio, espandendo l'API pubblica della tua classe puramente per soddisfare i tuoi test unitari), allora è un buon segno che la tua classe ha troppo lavoro da fare.
Puoi risolvere questo problema rifattorizzando la tua classe e spostando il codice del tuo tentativo di esporre nella sua stessa unità e iniettando un'istanza della tua nuova unità nella classe chiamante.
Preferisco rendere i metodi virtuali oltre l'estrazione di un'interfaccia. Il colpo di performance è trascurabile. In Java, dove i metodi sono virtuali per impostazione predefinita, le persone non si preoccupano tanto di questo.
Ho visto troppe codebase in cui ogni classe ha un'interfaccia corrispondente nello stesso spazio dei nomi. Rende il progetto confuso, poiché non sai se un tipo di interfaccia è un'astrazione o semplicemente un artefatto di test.
Leggi altre domande sui tag unit-testing c# mocking