Sto affermando l'ovvio?

La best practice, qui, è: "Parla con il tuo manager."

Questo check-in avrà ripercussioni e tu lo sai , potrebbe scramble il flusso di lavoro, le persone potrebbero decidere di correggere questi bug e perdere le scadenze sulle funzionalità che erano lavorando su, forse alcuni di questi bug sono davvero semplici da risolvere, ma il lavoro di alcune persone verrà deviato attorno a questo evento.

Ci sono alcuni che riescono a fare.

Inoltre ci possono essere parti dell'immagine più grande che sono oscurate dalla tua vista e conseguenze che non puoi prevedere. (interdipendenze / scadenze / contratti / versioni e librerie già distribuite in produzione)

Se fossi il tuo manager, apprezzerei la tua considerazione prima di verificarlo e ti consiglierei su come gestirlo meglio.

Se sei il manager, mi chiedo perché lo stai persino chiedendo.

nUnità ha annotazione [Ignore] . Direi che altri framework di test hanno un modo simile per ignorare i casi di test.

Qualsiasi test runner mostra quindi quanti test sono stati ignorati. In questo modo puoi tenere traccia di quanti test vengono ignorati e creare una sorta di "correzione di tutti / alcuni test ignorati ogni settimana / sprint".

La procedura migliore non è quella di cambiare i test a meno che non si preveda anche di modificare il codice associato per eventuali bug rilevati. Se ti è stato assegnato il compito e la priorità di cambiare i test, passare un giorno o due a fissare bugs a bassa priorità scoperti è, come direbbe Anakin, implicito nel tuo mandato.

Se hai inavvertitamente scoperto settimane di lavoro a bassa priorità, il che è dubbio, devi mettere le storie degli utenti sul backlog o sul tracker dei problemi in modo che il lavoro non venga dimenticato. La maggior parte dei framework di test consente di contrassegnare un test come ignorato, quindi è ancora presente, ma viene segnalato e conteggiato come ignorato in modo da non essere completamente dimenticato e deve almeno essere mantenuto al punto di compilabilità.

I bug possono avere bassa priorità ma i test fragili che falliscono a causa di questi cambiamenti sono una minaccia. Correggi i test ora. I test hanno lo scopo di semplificare il processo di refactoring, non più difficile. Fai attenzione a non scrivere semplicemente la prossima generazione di test fragili. Una volta aggiustati, rivaluta come ti senti riguardo ai bug "a bassa priorità".

I test non sono un proiettile d'argento. Non acquisisci magicamente saggezza superiore perché hai scritto un test che sembra avere senso. Se i bug che hai scoperto avessero delle correzioni ovvie e facili, non ti chiederei di sistemarli. Vuoi che sia facile ma non lo è. Ora hai un test fallimentare e non sai cosa farne. Conosco tre soluzioni qui:

• Risolvi il problema
• Elimina il test
• Scrivi un test migliore che semplifica la risoluzione del problema

Hai detto qualcosa che sto ancora aspettando di avere un senso. Perché le convalide che raramente falliscono devono essere disattivate? Si suppone che la convalida catturi un input errato prima che diventi uno stato. Ciò accade raramente non è un motivo per preferire raro cattivo stato rispetto a rari errori di convalida.

Non ho idea di quali problemi ti riferisci ma l'unica cosa che odio più di ciò che fallisce silenziosamente sono cose che falliscono silenziosamente solo quando ne hanno voglia.

L'unica buona ragione per cui posso pensare che questo ti leghi in nodi è che sta succedendo da qualche parte che non hai un buon modo per gestire un errore di convalida. Se questo è il problema devi crearne uno.

La regola dovrebbe essere che tutti i test dovrebbero sempre avere successo, e se non passano, i bug devono essere corretti (tenendo conto che un test unitario può avere un bug e deve essere corretto).

Detto questo, se la tua squadra si trovasse nei guai se impegni tutti i tuoi test unitari adesso , potrebbero essere messi su qualche ramo, e ogni volta che qualcuno ha il tempo di lavorarci sopra, scelgono alcuni test, eseguirli, correggere i bachi e commettere quei test con le loro correzioni.

MSTest offre un attributo TestCategory . Cioè, puoi contrassegnare quei test con

[TestMethod]
[TestCategory("WaitingBugs")]

Durante una build "normale", puoi escludere i test per categoria,

mstest.exe ... /category:"^!WaitingBugs"

È vero, rimane un problema: qualcuno deve ricordare che ci sono alcuni test che normalmente non vengono eseguiti ...