Convincere il mio capo che toccare il Database è test di integrazione [chiuso]

Penso che quando hai a che fare con persone che pensano di sapere meglio, o sei solo in una posizione in cui non pensano che dovrebbero ascoltarti, il modo migliore è mettere in discussione i loro modi.

È probabilmente il tipo che crede che dovrebbe essere lui a prendere le decisioni (indipendentemente dal fatto che sia o meno il più qualificato). E dicendogli che la tua opinione non è molto utile. Devi piantare un seme in lui che possa aiutarlo a prendere una decisione nuova e migliore.

Invece di dire al tuo capo come dovresti strutturare i tuoi test, dovresti mettere in discussione i suoi modi - "perché credi che i test che colpiscono il database siano test unitari quando ogni risorsa ben rispettata dice che i test unitari non dovrebbero toccare il database? "," I test unitari non dovrebbero essere indipendenti? Come possono essere quando toccano un database condiviso? Non dovrebbero essere in grado di funzionare in parallelo? "

Dici che è abbastanza incoerente con se stesso, che penso dovresti concentrarti su. "Non capisco, quando dici che i test di integrazione sono ... ma poi dici che ... non è / anche un test di integrazione?"

Se gli dici semplicemente che "i test unitari non devono toccare il database", gli stai solo indirettamente dicendo "hai torto, ho ragione", e inizierà a essere sulla difensiva. Se metti in dubbio i suoi modi, lo stai costringendo a pensare.

È importante che tu esprima le tue domande in un modo in cui cerchi davvero di capire il suo punto di vista. In caso contrario, le vostre domande saranno solo una versione leggermente modificata del dettare il vostro punto di vista, e il dibattito diventa rapidamente stancante per entrambi. E forse ha un punto valido da qualche parte che dovresti anche capire.

Disclaimer: ora ho provato ad analizzare il tuo capo senza averlo mai incontrato, il che è ovviamente impossibile. Ma lo scenario che descrivi è coerente con un modello che ho visto prima.

Penso che tu stia andando in questo modo nel modo sbagliato. Non entrare in discussione sulle definizioni di parole, non è utile. Cercare di discutere dei cambiamenti nella metodologia di sviluppo discutendo sulla definizione di un test di integrazione, è come provare a quadrare un cerchio cambiando la definizione di un quadrato.

Invece, sostieni quello che vuoi davvero cambiare. Vuoi la possibilità di testare la funzionalità senza colpire il database? Quindi presenta un caso perché sarebbe utile. Vuoi eseguire i test più velocemente? Quindi mostra come può essere fatto. Vuoi un codice più pulito non mescolando la logica del database ovunque? Mostra i vantaggi.

Appellarsi a una definizione che dice che "l'accesso al database non appartiene ai test di integrazione" è solo setta del carico. Invece, ci spiega perché dovremmo evitare l'accesso al database nella suite di test principale. Penso che troverai le definizioni seguenti.

Sfidare qualcuno che pensa di conoscere meglio è sempre un problema. Hai incontrato qualcuno che crede "tutto è un test unitario" e questo tipo di errata classificazione è difficile da affrontare.

Forniscigli una scala di interazioni, che ha una certa gerarchia ad essa. Chiedigli di tracciare linee dove vuole definire le cose. Ad esempio.

1. Metodo / procedura singoli, senza effetti collaterali; restituisce zero o più valori.
2. Metodo / procedura singola, gli effetti collaterali influenzano la classe in cui si trova solo; restituisce zero o più valori.
3. Metodo / procedura singoli, senza effetti collaterali ma utilizza una libreria importata.
4. Metodo / procedura singoli, senza effetti collaterali ma utilizza altre classi / metodi che fanno parte del codice in prova.
5. Metodo / procedura singoli, senza effetti collaterali, ma legge il database utilizzando la libreria JDBC. ... e così via.

A che punto traccia le linee per i test "Unit", "Functional" e "Integration"?

Ecco una scala simile: 1) classe singola, 2) classe singola più un paio di giare, 3) classe singola più database in memoria JDBC / H2, 4) classe singola più JDBC / MySQL sulla stessa macchina, 5 ) singola classe più JDBC / Oracle su una macchina di database separata.

Un'altra scala: 1) tempo di test del secondo millisecondo, 2) decimo di secondo di tempo di test, 3) tempo di test inferiore al secondo.

Immagino che ci saranno molti altri fattori che entrano in gioco che potresti non aver considerato. Probabilmente sono non tecnici. Ad esempio, tempo, impegno, comprensibilità, semplicità, futuri lavori futuri, decisioni precedenti già prese, ecc.

C'è ovviamente un sacco di conflitti attorno al database. Devi fare un passo indietro, è ovviamente molto orgoglioso di questo, e bussare non aiuterà il tuo caso. Se è veloce, è una buona cosa.

Potrebbe benissimo essere che i tuoi punti siano abbastanza validi, e potrebbe essere respinto a causa del modo in cui li stai suggerendo.

Inoltre, rilassati, ricorda che nessuno è mai morto a causa della presa in giro di un'applicazione:)