Test delle unità: inversione delle dipendenze

Question

Test delle unità: inversione delle dipendenze

#1 da (1 voti)

-1

Sto cercando di iniziare ad aggiungere alcuni test al mio codice. Per favore, rilassati perché sono ancora nuovo in questo campo.

Per quanto comprendo l'inversione di dipendenza, tutte le dipendenze saranno collocate all'interno di un costruttore di classi e devono essere un'interfaccia in modo che possiamo facilmente falsificarlo. Seguendo questa regola potrei finire con una classe di login come questa.

public class Login
{ 
    string _username;
    string _password;
    IUserRepository _userRepository;
    public Login(string username, string password, IUserRepository userRepository)
    {
        this._username=username;
        this._password=password;
        this._userRepository=userRepository;
    }
}

public interface IUserRepository 
{ 

}

Questo è contrario a come capisco che le classi saranno. Credo che gli utenti del tuo codice non debbano sapere nulla del suo funzionamento interno. Tutto quello che devono sapere è come istanziare e usare l'oggetto. In breve, fornisci loro un modo per arrivarci, ma nascondi i dettagli. Quindi, per riassumere, avere il repository IUser all'interno di un costruttore ha reso il mio codice più confuso per alcuni utenti della mia classe. Per favore illuminami su questo in modo da non commettere altri errori lungo la strada.

Saluti,

unit-testing c#

posta Denden 30.10.2017 - 05:11

fonte

1 risposta

Leggi altre domande sui tag unit-testing c#

Come dovrebbe essere definita la tabella Utenti nel database se un'app intende consentire l'iscrizione e l'autenticazione da più piattaforme? Dovrei usare la mia implementazione MVVM?

score 1 · Answer 1

Penso che una cosa fondamentale da capire è che nel codice DI, la creazione di un oggetto e il suo utilizzo avvengono in due fasi o contesti drasticamente separati.

Nella prima fase, subito dopo l'inizio del programma, viene utilizzato il contenitore DI per creare un grafico dell'oggetto. Ciò significa chiamare i costruttori di classi e passare le dipendenze create allo stesso modo. Solo le informazioni conosciute, che possono influire su quali oggetti sono costruiti, a questo punto è probabilmente una sorta di configurazione. Quindi nel tuo esempio non ci sono dati forniti dall'utente, come nome e password.

Dopo che questa fase è terminata, viene chiamato un oggetto "entry" e tutto inizia ad eseguire il codice che interagisce con l'utente / il mondo. Ma questa volta, la maggior parte delle chiamate dovrebbero essere chiamate ai metodi e la creazione di nuovi oggetti all'interno del grafico dell'oggetto iniziale dovrebbe essere rara-ish.

Ma non è impossibile creare una nuova classe mentre il programma è in esecuzione. Per assicurarsi che l'utente non debba conoscere le dipendenze della classe che sta cercando di creare, viene utilizzato un AbstractFactory . Per il tuo codice, la fabbrica astratta sarebbe simile a questa:

public interface ILoginFactory
{
    Login Create(string name, string password);
}

public class LoginFactory : ILoginFactory
{
    private readonly IUserRepository _userRepo;
    public LoginFactory(IUserRepository userRepo)
    {
        _userRepo = userRepo;
    }

    public Login Create(string name, string password)
    {
        return new Login(name, password, _userRepo);
    }
}

In questo modo, chi crea una nuova classe Login non ha bisogno di sapere della sua dipendenza transitiva su IUserRepository .