Perché il mio team non desidera eseguire automaticamente i test unitari?

Innanzitutto, grazie a @Gnat per trovare informazioni sul problema reale qui e darmi quello che dovevo sapere per arrivare al vero problema.

Abbiamo concordato di isolare i test unitari e i test di integrazione nei loro progetti per garantire che il codice di test aggiunto non venga compilato nella compilazione.

Stiamo anche eseguendo i test in un flusso di lavoro non bloccante finché non saremo in grado di separare il codice in repository più piccoli in modo che ogni build non impieghi 15-30 minuti.

E per ora, abbiamo concordato di non costruire il progetto su ogni Pull Request (PR), ma di eseguire i test su una build notturna. Questo è quello che intendevano veramente con i test che rallentavano le cose ... In realtà, significavano fare un build su ogni PR. Fanno decine di volte al giorno. La loro preoccupazione principale per i test che bloccavano una build urgente, era la loro preoccupazione che le build urgenti finissero spesso con decine di PR, quando tutti cercano di unire il loro codice in una volta, e volevano essere in grado di eseguire i test alla fine di quel processo, e non richiedono una costruzione separata in ogni punto lungo la strada.

Non c'era una sola risposta che mi fornisse tutte le informazioni di cui avevo bisogno e la maggior parte delle risposte migliori arrivavano nei commenti, quindi ho creato questa risposta per riepilogare tutto ciò che ha più senso.

Le informazioni importanti che mi mancavano erano:

• Se i test sono troppo vicini al codice sotto test, allora è molto dispendioso dire a .net di non creare i file di test nei file .dlls, ed è molto più facile mantenerli come progetti separati.
• Il vero problema era la build richiesta per eseguire i test. Non erano i test che non volevano correre, era la build. Non volevano che la build impedisse loro di unire il codice frequentemente come fanno. A livello locale, sui propri computer, sono in grado di eseguire una compilazione di debug ed eseguire i test in meno di un minuto, ma sui server CI richiede molto più tempo.

I'm managing a team in .net.

Non importa.

They are writing unit tests ... and only wants to run them once a week or so.

I test unitari non vengono eseguiti una volta alla settimana. Li esegui prima e dopo aver scritto la più piccola quantità di codice che puoi per farli passare. I test sono generalmente buoni, ma qualunque essi siano non sono unit test.

and love it.

Bene.

However they keep pushing to have the unit tests kept as a separate project

Non importa.

Our js teams are running tests on every commit.

Questo è tutto? O si commette molto spesso o non si prova molto. Primo test localmente.

Ciò che è rimasto fuori da questa storia è la frequenza con cui stai refactoring dei test. Sono questi test un guardiano trincerato che richiede uno sforzo erculeo per cambiare? I test di refactoring dovrebbero essere fatti come semplici e spesso come codice di refactoring.

I keep trying to explain to them the benefits of having the tests near the code, and running the tests often, but they keep bringing up fears of the builds being too slow, or what happens when the tests prevent an urgent build.

Dovrebbero essere autorizzati a mettere i test ovunque possano lavorare. Devono anche sapere come localizzare una build per le classi che hanno effettivamente toccato in modo che non si tratti di un problema.

Sarebbe assurdo fare test progettati per funzionare "una volta alla settimana" e inserirli in un'integrazione continua. Piuttosto li hanno aggiunti nuovi test progettati per essere eseguiti nell'integrazione continua che sarà sintonizzata sulle prestazioni necessarie.

Il termine di fantasia per questi nuovi test è: test di integrazione continua . Non sono anche test unitari. Il modo migliore per categorizzare i test è basato sulle prestazioni che ti servono. Non gli strumenti che usi per eseguirli. In questo modo i test che si comportano allo stesso modo sono insieme.

Non prendere il controllo dei test dagli sviluppatori. Offri loro strumenti che permettano loro di controllare nuovi tipi di test.

but they keep bringing up fears of the builds being too slow, or what happens when the tests prevent an urgent build.

Che cosa succede se dovresti impedire una build urgente perché stai per eseguire il commit di un codice bug, ma non farlo perché non hai eseguito i test che ti dicono che sei introduzione di codice errato?

Sembra che la tua squadra stia esaminando i test come un ostacolo piuttosto che uno strumento. I test sono la loro rete di sicurezza, il loro canarino nella miniera di carbone. Se le build sono troppo lente, allora forse sta dicendo loro qualcosa che hanno bisogno di sapere sul software. Se continuano a spazzare il problema della lenta costruzione sotto il tappeto, continuerà a rappresentare un problema.

In primo luogo, i progetti separati per i test unitari sono buoni . Tenere il codice di prova dell'unità lontano dal codice principale è la separazione delle preoccupazioni e tutto quel tipo di cose interessanti.

In secondo luogo, non si può prescindere dal fatto che i test unitari, se eseguiti come parte della build, rallenteranno le cose e potrebbe fare la coda per le build. Non parli di cosa stai usando per costruire (TFS, TeamCity, Jenkins, ecc.) Ma ci sono cose che puoi fare per mitigare questo tipo di code e priorità multiple. Parla con il tuo gestore di build.

Se c'è una build urgente che deve saltare la coda, il build manager dovrebbe essere di nuovo il primo punto di riferimento. Potrebbero essere in grado di ridurre le build di priorità e spingere la build urgente più in alto nella coda.

Infine, citi l'IC ma non menzioni se è chiuso. Cioè: il nuovo codice viene espulso nella sua interezza se i test di costruzione o unità falliscono. Ciò può indubbiamente essere controverso in quanto il codice può in teoria funzionare, ma alcune condizioni possono causare il fallimento dei test.

C'è ahimè, nessun proiettile d'argento qui. Quando ero un direttore di costruzione, ho incontrato spesso un'enorme resistenza quando il codice è stato espulso, specialmente se la scadenza era imminente. Quante volte ho sentito il ritornello: "Il TFS continua a schiantarsi, basta disattivare l'impostazione e lasciare che controlli il codice!". Senza eccezione, lo sviluppatore era in errore. Avevano dimenticato di includere un file nel check-in o semplicemente non aggiornavano il test quando il codice cambiava, come avrebbe richiesto troppo tempo.

Hai seriamente bisogno di prendere l'abitudine di respingere lo sviluppatore qui altrimenti si imbatteranno in te per sempre. Se un altro sviluppatore estrae codice spezzato che hai permesso solo perché un altro sviluppatore inizia a piagnucolare, non sarai popolare.

Credo che sia dovuto al tipico problema di "riluttanza a cambiare" che studiamo sempre nell'ingegneria del software. Non riesco a pensare a un vantaggio per tenere separati i Test unitari (ho lavorato in JS, Java, .Net e ABAP), ma posso vedere la solita ragione: "Lo abbiamo fatto per molto tempo e ha sempre funzionato, quindi è necessario cambiare ".

Spero che questo abbia aiutato. sarei anche interessato a sapere se c'è un vero motivo.

they keep pushing to have the unit tests kept as a separate project

I test dovrebbero andare in un progetto separato. Questa è una pratica standard

mySolution
    myProject
    myProject.Tests

and only wants to run them once a week or so.

Questo è un po 'strano, sebbene se si tratti di test dell'interfaccia utente, è possibile eseguirli durante la notte. Però. Accetto e fai controllare i test.

Puoi avere il 'perché non li eseguiamo al check-in?' e "perché non permettiamo l'unione quando i test falliscono" le conversazioni in un secondo momento.