Test di unità basati sui dati

Question

Qual è la migliore pratica per testare un'API che dipende dai dati del database? Quali sono i problemi a cui devo fare attenzione in una "Integrazione continua" ambiente che esegue Test unit come parte del processo di compilazione? Voglio dire, distribuiresti il ??tuo database come parte degli script di compilazione (potrebbe essere eseguito il tuo programma di installazione) o dovrei cercare dati hardcoded [usa MSTest Data Driven Unit Test con XML]?

Capisco di poter deridere il livello dati per il livello Business Logic, ma se avessi problemi nelle mie istruzioni SQL in DAL? Devo colpire il database, giusto?

Beh ... questo è un torrente di domande:) ... Pensieri?

Answer 1

Per quanto possibile dovresti deridere il codice per evitare di colpire del tutto il database, ma mi sembra che tu abbia ragione sulla necessità di testare il tuo SQL da qualche parte lungo la linea. Se si eseguono test che colpiscono il database, un suggerimento chiave per evitare mal di testa è assicurarsi che la propria configurazione porti i dati in uno stato noto, piuttosto che fare affidamento sul fatto che siano già disponibili dati adeguati.

E ovviamente, non testare mai contro il tuo database live! Ma questo è ovvio :)

Answer 2

Come accennato, usare il derisione per simulare le chiamate DB nei test unitari a meno che non si desideri manipolare i test e i dati all'infinito. Testare le istruzioni sql implica più di un test di integrazione . Esegui quello separato dai test unitari, sono 2 diversi animali.

Answer 3

È una buona idea cancellare automaticamente il database di test e quindi popolarlo con i dati del cablaggio di test che si presume siano presenti per tutti i test che devono connettersi al database. Il database deve essere ripristinato prima di ogni test per un corretto isolamento: un test non riuscito che inserisce dati errati può causare falsi fallimenti sui test che seguono e diventa disordinato se si devono eseguire test in un certo ordine per risultati coerenti.

Puoi cancellare e popolare il database con strumenti ( DBUnit , DBUnit.NET , altri) o crea semplicemente le tue classi di utilità per fare la stessa cosa.

Come hai detto, altri livelli dovrebbero essere sufficientemente disaccoppiati dalle classi che colpiscono effettivamente il database, quindi la necessità di qualsiasi tipo di database coinvolto nei test è limitata ai test che eseguono un piccolo sottoinsieme della tua base di codice. I componenti che accedono al database possono essere derisi / cancellati per tutto ciò che dipende da essi.

Answer 4

Una cosa che ho fatto è stata creare metodi statici che restituivano dati di test di uno stato noto. Vorrei quindi utilizzare un "falso" DAL per restituire questi dati come se stessi effettivamente chiamando il database. Per quanto riguarda il test della procedura sql / stored, l'ho testato usando SQL Management Studio. YMMV!