Codice di test unitario che si basa su un codice di terze parti non testabile [duplicato]

Normalmente aggiungo un livello di astrazione per un componente di terze parti.

Dire che ho una classe statica chiamata User:

public static class User
{
   public static void Login(string username, string password)
   {
      // Logic
   }
}

Immagina che User sia un componente di terze parti per l'autenticazione.

Creerei quindi un'interfaccia che rappresentasse il comportamento della mia classe statica:

public interface IUser
{
   void Login(string username, string password);
}

Creerei quindi un'implementazione predefinita che parlerebbe con la classe statica:

public class UserDefault: IUser
{
   public void Login(string username, string password)
   {       
       User.Login(username, password);
   }
}

User è un componente di terze parti e non è necessario testare la logica dell'unità. Quello che potrei voler fare nel mio test unitario è verificare che abbia chiamato User.Login("admin","Foo") una sola volta.

Nel mio test unitario ora posso creare un oggetto mock basato su IUser e impostare le aspettative su quel mock.

Poche cose prima di esaminare cosa si può fare
- Test del codice che noi autori di lavorare come previsto è un must - Avere il codice di prova nel codice di produzione è IMO un codice olfattivo

In realtà, il modulo che creiamo dipende da librerie e altri componenti 1 > Le librerie potrebbero essere create da altri team all'interno dell'azienda 2 > Le librerie potrebbero essere create da società terze parti

Se la libreria è stata creata da terzi o da un'altra società Sappi che la terza parte è uno dei fornitori adatti per la libreria (non l'unica)
Potrebbe esserci un fornitore di soluzioni migliori emergenti domani
Quindi è necessario progettare la dipendenza in modo da poter passare facilmente da una soluzione all'altra Quindi suggerirei, pensate di isolare l'utilizzo di librerie di terze parti e associare liberamente la vostra soluzione con la libreria di terze parti
Puoi farlo introducendo un'interfaccia per racchiudere le funzionalità di terzi Ciò ti darà un ulteriore vantaggio di rendere il tuo codice testabile, cioè durante il test, simulerai la capacità di libreria di terze parti e testerai vari scenari

Se la libreria è creata da un team diverso all'interno della tua azienda
Un approccio è ancora isolare la capacità della libreria definendo le interfacce
Ma vorrei suggerire che questo è un approccio FIP (Frog in the pond) che non sarebbe vantaggioso a lungo termine In questo caso ti suggerisco di parlare con gli altri membri del team e aiutarli a vedere la luce Spesso, quando ciò non è possibile, gli architetti di sistema / i lead di progetto devono inserire