Utilizzo di un flag nel repository in memoria per indicare l'aggiornamento all'entità

Question

Utilizzo di un flag nel repository in memoria per indicare l'aggiornamento all'entità

#1 da (1 voti)

0

Sto per scrivere un sacco di test per la mia applicazione. Mentre alcuni test verificano se tutto funziona se l'utente inserisce i dati corretti, la maggior parte di essi gestisce dati errati / mancanti. In questi casi, nulla dovrebbe essere aggiornato e dovrebbe essere lanciata un'eccezione.

Al momento, questo porta a un sacco di codice duplicato, perché ogni test deve assicurarsi che non venga generata solo l'eccezione, ma nessun dato nel mio ( ~~mocked~~ in-memory) database è cambiato.

La mia prima idea è stata quella di spostare questi test in una funzione e di chiamare questa funzione in ogni test. Pro: Posso ancora usare test molto espliciti. Contro: Devo ricordare di aver cambiato la funzione e aggiungere altri test ogni volta che aggiungo più funzionalità alla funzione selezionata.

Ma potrei anche aggiungere una proprietà al mio repository in-memory ~~mocked~~ che indica se un'entità è stata aggiornata. Pro: Non dovrò mai preoccuparmi di un assegno dimenticato. Contro: Il controllo è abbastanza vago - Quando fallisce saprò solo che qualcosa è stato cambiato. Per trovare l'errore dovrò eseguire il debug passo dopo passo attraverso la funzione.

Qual è l'approccio migliore? Forse c'è una terza soluzione ancora migliore?

testing assertions

posta Christopher 04.09.2013 - 19:27

fonte

1 risposta

Leggi altre domande sui tag testing assertions

Problemi di pubblicazione di un tema WordPress, basato sul tema delle radici, su Themeforest E 'così che funziona Simplex Noise?

score 1 · Accepted Answer

Sei sicuro di parlare effettivamente di un Mock e non di uno stub (o di un falso) ?

I mazzi non hanno "bandiere" - li configuri per comportarti come vuoi, quindi se ci fosse in effetti una bandiera allora quella bandiera sarebbe stata derisa e quindi priva di significato per il test.

Usi i mazzi per verificare le interazioni con un componente dipendente. Nel caso di un repository, dovresti solo verificare che un particolare metodo di aggiornamento sia stato non chiamato, che in tutti i framework di simulazione che conosco è solo una riga di codice.

Il fatto che i repository siano così banalmente facili da deridere e verificare è uno dei principali (solo?) motivi per usarli in primo luogo.

Se la linea di verifica è lunga ad es. a causa di un metodo che ha molti parametri o qualcosa di certo sicuro, rifattilo su un metodo di test comune. Se in realtà inizia a diventare disordinato, puoi creare un generatore di test fluente che estrae i passaggi e le verifiche più comuni, in modo che i test sembrino una sorta di DSL. Ma quando dico "disordinato" sto parlando letteralmente di centinaia di questi test; meno di una dozzina e sicuramente non ne vale la pena o la complessità aggiunta.

Tieni presente che i test unitari sono specifiche e dovrebbero dirti in termini molto semplici come si comporta effettivamente il codice. Anche se è importante mantenere il codice di prova pulito e periodicamente refactoring, è anche importante non esagerare e finire con la creazione di un codice di test complesso come il SUT.

Non so esattamente quali siano le tue specifiche, ma se includono qualcosa come "non dovrebbe aggiornare l'entità X con ID Y", allora è esattamente come dovrebbe apparire il codice di test, e un Mock è il più appropriato strumento. D'altra parte, se le tue specifiche parlano dello stato finale dei dati (es. "Entità X dovrebbe ancora stato Y e non Z") allora un Mock non è una scelta molto buona, ti consigliamo di usare un vero e proprio falso database - di solito un database in memoria - e i tuoi test in realtà cercano quelle entità e le controllano. In entrambi i casi, non vedo quale proprietà si possa aggiungere al repository stesso che sarebbe di grande aiuto.