È utile per unità di metodi di prova in cui l'unica logica è guardie?

Part of me says "sure you can unit test them, but it is not worth the time" (I am on a project that is already behind schedule).

Sono tre test molto brevi. Hai passato tutto il tempo a pormi la domanda.

But the other side of me says, if you don't unit test them, and someone changes the Guards, then there could be problems.

Ascolta questo lato.

But the first part of me says back, if someone changes the guards, then you are just making more work for them (because now they have to change the guards and the unit tests for the guards).

Se il tuo manutentore è un matto TDD, lo stai rendendo più difficile per loro. Qualsiasi cambiamento che faccio senza che ci sia un cambiamento o aggiunta di test, porta a dover pensare seriamente. In effetti, probabilmente aggiungerei i test prima di andare avanti e apportare la modifica.

La prima parte di te è semplicemente sbagliata. Dare alla seconda parte una pacca sulla spalla e smettere di pensarci.

Semplificherebbe il test delle unità se la logica di guardia e l'ordine effettivo fossero metodi separati.

Nella classe Widget

public bool IsReadyForOrdering { get { return PartNumber > 0 && PartAvailable; } }

o un metodo equivalente da qualche altra parte

public bool IsWidgetReadyForOrdering(Widget widget)
{
    return widget.PartNumber > 0 && widget.PartAvailable;
}

Il metodo dell'ordine

public void OrderNewWidget(Widget widget)
{
   if (IsWidgetReadyForOrdering(widget)) {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

Ora testare IsWidgetReadyForOrdering è diventato facile. Non pensarci più a lungo. Provalo!

Se non hai tempo nel tuo programma per i test unitari ma hai tempo da dedicare per un solido utilizzo del QA, chiedi se puoi rubare parte di quel tempo di QA per scrivere test unitari, o se puoi spendere alcuni dei il periodo di QA fa test unitari, o forse mi occupo solo di codice non unitario testato. Sfortunatamente programmi che sono inamovibili per farti concessioni o per costringerti a morire, generalmente ti suggerisco la prima opzione perché la seconda ti renderà incapace di supportare / mantenere il sistema correttamente per il suo termine.

Detto questo, alla tua domanda generale di testare le dichiarazioni della guardia; Sì! Assolutamente dichiarazioni di test-test! Quelle sono parti importanti del comportamento di quel metodo, non vorresti scoprire che qualcuno ha frainteso qualcosa facendo un bug-fix e rimosso le tue guardie o cambiato && in || , vero? I test unitari garantiranno che a) hai effettivamente corretto la logica delle tue guardie e b) nessuno interrompe la logica in seguito senza ricevere un reclamo quando eseguono i test unitari dicendo loro che dovrebbe essere così per qualche motivo.

Ci sono alcune risposte eccellenti sopra, e i punti che fanno sono molto importanti. Ma quello che sembra essere mancato è quello di voi che avete una serie completa di test unitari, che leggono come una specifica estremamente dettagliata del codice. Se ometti la convalida del test solo perché il codice è così semplice, è difficile vedere come potrebbe andare male, manca una parte della tua specifica. Se fossi entrato in una squadra in cui questi test erano stati omessi, in realtà pensavo che il tuo servizio non stesse convalidando i suoi argomenti.

Il codice è codice. Dovresti provare a ottenere una copertura del 100% durante i test. Se non fosse importante non sarebbe lì.