I test unitari sono stati scritti esclusivamente per soddisfare un debito tecnico in termini di copertura del codice?

Sì, direi che si tratta di un debito tecnico. Il codice di prova non è diverso dal codice da testare in quanto deve essere mantenuto e compreso. Il fatto che non si capisca il punto del codice di test è un problema di manutenzione in quanto non aiuta a capire il codice che viene testato; una grande componente di ciò che rende il test utile per cominciare. Questo rende le cose più difficili del non avere alcun test.

Il requisito di copertura indica anche un problema non di codice, che è uno sviluppatore a cui non interessa abbastanza fare correttamente il suo lavoro. Non capire il codice è una scusa scusa per scrivere test inutili solo per soddisfare la build. Anche questo dovrebbe essere indirizzato. Se questo è un comportamento tipico per John, cercherei di farlo fuori dalla mia stessa squadra.

La metrica di includere nella build è probabilmente un tentativo di convincere persone come John a scrivere effettivamente i test che dovrebbero fare. È molto più difficile giustificare la mancata scrittura di test se il risultato è una build non funzionante, che in genere viene presa in seria considerazione dai team di software.

I nuovi test costituiscono un debito tecnico?

Sì. Alla fine, questi orribili test dovranno essere modificati, probabilmente da Jane quando tornerà dallo snowboard. A quel punto, avrà difficoltà a comprendere i test.

Che cosa dovrebbe essere fatto su di loro (se possibile)?

Se i test orribili sono accettabili a breve termine, tienili. In caso contrario, risolverli. Quando Jane torna dallo snowboard, dovrebbe eliminare tutti i nuovi test e sostituirli con test accettabili (supponendo che sia la persona migliore per farlo).

Il tuo debito tecnico è stato introdotto nel punto in cui la funzionalità è stata implementata senza copertura del test appropriata.

A meno che tu non stia letteralmente meglio senza quei test unitari, (nel qual caso cancellali ora) direi che non è appropriato affermare che i test stessi costituiscono un debito tecnico. Piuttosto, i test sono un tentativo sub-par per affrontare l'assenza di una copertura di test appropriata.

I nuovi test non costituiscono un debito tecnico semplicemente perché sono stati scritti per soddisfare una metrica di copertura del codice. La ragione per scriverli è ora nel passato. Problemi particolari con i test possono essere il debito tecnologico, ma senza sapere di più su questi problemi non possiamo dire se ci sono problemi che possono essere risolti meglio eliminando i test.

Ciò che dovrebbe essere fatto in merito ai test ora dipende da quale sia la natura dei test e da quali sono i loro effetti, piuttosto che dalla motivazione di John per scriverli. Conservali se sono utili, cancellali o modificali se sono dannosi.

Non dici se questi sono test senza asserzione . I test senza asserzione hanno scarso valore, sebbene possano rilevare alcuni bug in particolare se il codice è un linguaggio interpretato in cui non si dispone di una fase di costruzione per rilevare sintassi e digitare errori. Se sono privi di asserzione, potrebbe valer la pena tenerli ma aggiungere affermazioni.