Test automatici per la funzionalità "crea utente", che richiedono dati univoci

Ho preso il suggerimento di cr3. Ho usato il Bogus lib per C #. Utilizzando il Bogus lib e Microsoft.VisualStudio.TestTools.UnitTesting sono riuscito a creare dati di test casuali per ciascun test che lo richiedeva. Ho usato la parola "Purge" nei dati casuali in modo che potesse essere trovata e rimossa in seguito. Volevo pubblicare un esempio, poiché è quello che cercavo in origine.

[TestInitialize]
    public void Initialize()
    {
        //Replace a formatted string with random numbers #, letters ?, or * random number or letter
        var faker = new Faker("en");

        StudentAuthIdRandom = new Bogus.Randomizer().Replace("???:???:???-Purge");
        FirstNameRandom = new Bogus.Randomizer().Replace("????-Purge");
        MiddleNameRandom = new Bogus.Randomizer().Replace("?????-Purge");
        LastNameRandom = new Bogus.Randomizer().Replace("??????-Purge");         
        UserNameRandom = new Bogus.Randomizer().Replace("????????-Purge");
        UserPasswordRandom = new Bogus.Randomizer().Replace("?*****-Purge");
    }

Nota: ho appreso dalle altre risposte che quello che sto facendo è un test di integrazione (non di unità) e ci dovrebbe essere un DB dedicato per questo. Avere un DB dedicato per questo lavoro non era un'opzione per me quindi ho usato i valori dei dati che potrebbero essere facilmente trovati e rimossi per il dev BD che stiamo usando.

grazie per tutte le risposte e i suggerimenti

È normale avere bisogno di valori unici durante il test. Quindi, potresti voler cercare una libreria che già fornisce quella funzionalità per te.

Se non riesci a trovare una libreria esistente, puoi prendere in considerazione la possibilità di eseguire il rollover con la riutilizzabilità in mente:

• Si potrebbe iniziare con la generazione di un numero intero univoco. La prima implementazione potrebbe utilizzare il timestamp come suggerito. Se a volte ciò causa collisioni, è possibile che si desideri inizializzare solo un contatore con un timestamp e incrementarlo in ogni chiamata. Se esegui i test in più thread o più processi, puoi modificare di conseguenza.
• Puoi continuare a generare una stringa univoca. La prima implementazione potrebbe utilizzare lo stack per includere il nome file e il numero di riga del chiamante nella stringa, a cui è possibile aggiungere l'intero univoco nel punto elenco precedente. Se questa stringa generica rende difficile la risoluzione dei problemi, puoi parametrizzare la funzione in modo da ottenere un prefisso o un suffisso per renderlo più specifico.
• Potresti essere ancora più specifico con la creazione di un nome utente univoco. Se la generazione di una stringa univoca viola alcuni vincoli del nome utente, questa funzione potrebbe modificare la stringa di conseguenza. Ad esempio, se il nome file, il numero di riga e il numero intero univoco nella stringa univoca sono separati da trattini, ma quel carattere non è consentito in un nome utente, è possibile parametrizzare la funzione di stringa univoca per prendere un carattere separatore o sostituire semplicemente il carattere trattini nella stringa.

Costruendo una libreria, può essere facilmente testata in unità in modo che altri test possano usarla con sicurezza. Inoltre, riutilizzando le funzioni, è possibile migliorarlo in modo incrementale quando si verificano potenziali collisioni. Ad esempio, se si migliora la funzione intera univoca, saranno vantaggiose sia la stringa univoca che il nome utente univoco nel disegno sopra; per non parlare di tutti i test che utilizzano questa libreria.

Il tuo problema è probabile che il tuo codice di elaborazione sia strettamente collegato al tuo DB, prova a disaccoppiare e le cose diventeranno molto più semplici:

class StudentProcessor
{
     Func<string, bool> CheckUsernameIsUnique;
     public StudentProcessor(Func<string, bool> checkUsernameIsUnique)
     {
         CheckUsernameIsUnique = checkUsernameIsUnique;
     }

     public ... ProcessStudent(...)
     {
         CheckUsernameIsUnique(username);
         ...
     }
}

Ora è molto più facile testare cosa succede qui

void Test()
{
     var processor = new StudentProcessor(x => {"username1", "username1"}.Contains(x));
     processor.ProcessStudent(...);
}

Quello che è successo qui, è che i tuoi problemi di test delle unità ti hanno mostrato che la tua attuale implementazione ha un accoppiamento stretto che rende difficile la manutenzione. Questo non è un problema con il test delle unità, è il suo principale vantaggio:)

Sembra che tu stia scrivendo test di integrazione che richiedono un'API Web live. In questo caso, è perfettamente utile utilizzare l'API di Live Web a scopo di test, ma è necessario controllare il database.

Prima di ogni test, cancella il database pulito. Quindi inserisci esattamente i dati necessari per il test. Esegui il test. Affermare. Risciacqua e ripeti.

Se non stai testando l'integrazione della tua applicazione e dell'API, allora devi disaccoppiare quelle chiamate dalla tua logica di business principale, di solito definendo un'interfaccia per l'oggetto API Web e simulandola negli altri test.

Mi rendo conto che hai detto che non puoi controllare il database. Se questa è la verità, non dovresti includere il database come parte dello stack tecnologico sotto test.