Un test di unità può sostituire la macchina da lavorare al momento del completamento del lavoro?

Is a unit test a better replacement for works-on-my-machine?

Sì, è assurdamente migliore. A meno che tu non abbia una sorta di containerizzazione per garantire la configurazione del tuo ambiente, l'esecuzione sul tuo computer locale non garantisce nulla. E anche allora, farlo a mano è solo chiedere agli altri di rovinare facendo la stessa cosa a mano. I test unitari verificano che la funzionalità stessa funzioni, rapidamente, in modo affidabile, ripetibile.

Is it seen as unprofessional if I do not confirm the changes manually before passing work over to a test team?

Può essere. Diversi ambienti di lavoro hanno procedure operative e aspettative standard diverse. Mi aspetto che la maggior parte degli ambienti non si preoccupi del fatto che hai eseguito solo i test unitari o che non ti interessa abbastanza sapere che hai eseguito solo i test unitari.

Personalmente, verificherò solo manualmente le cose che per qualche motivo sono proibitive per il test unitario o vengono rilevate da uno stakeholder abbondantemente sensibile.

No. Hai bisogno di un test di integrazione o dell'interfaccia utente per verificare che tutto funzioni.

Idealmente, questi sono eseguiti su una sorta di ambiente di test piuttosto che sul proprio computer.

Se ti manca, probabilmente vale la pena passare attraverso l'installazione e testarla manualmente. Dopotutto è una cosa una tantum per quel sistema vero?

Utilizza una macchina virtuale e salva l'immagine per riutilizzarla.

I test di unità sono ottimi, ma non catturano elementi di base come la configurazione, il che interromperà il sistema tanto quanto un errore nel codice.

È una questione di costi. Supponiamo che il tuo codice funzioni in sei ambienti significativamente diversi e che i tuoi test unitari siano impostati per controllare tutti questi ambienti. E ci vorrebbero sei ore di lavoro per installare uno di questi ambienti sulla tua macchina.

In tal caso, sarebbe assolutamente logico controllare il codice sulla macchina così come è stata impostata (per trovare i bug che si verificano in qualsiasi ambiente) e quindi eseguire i test delle unità. Potresti essere in grado di eseguire tre round di test unitari e di fissare test non funzionanti nel tempo necessario per configurare un ambiente.

I test unitari sono una buona aggiunta a works-on-my-machine.

Dovresti sempre eseguire anche i test di integrazione / manuali. È una brutta cosa fare solo test unitari.

Un buon modo per rendere il codice "funziona anche nella tua macchina" è avere un server di prova e un'integrazione continua come Jenkins. In questo modo, il codice verrà eseguito anche su altre macchine.

Dipende dalla politica del tuo team.

I test degli utenti locali possono coprire percorsi di codice diversi rispetto ai test dell'unità forniti. E più copertura è solitamente migliore. Le anomalie riscontrate nel test "fa-funziona-sulla-macchina" a volte sottolineano la necessità di ulteriori test unitari o altre procedure di test.

Ma la politica della tua squadra potrebbe essere quella di qualcun altro. Oppure, in piccoli gruppi, potrebbe essere il tuo lavoro assicurarsi che qualcosa funzioni al di fuori dell'ambiente di test.