Contro l'utilizzo di framework non vincolati per il test delle unità

Question

Contro l'utilizzo di framework non vincolati per il test delle unità

#1 da (1 voti)

6

È molto facile scrivere test unitari per codice legacy utilizzando framework non vincolati, come TypeMock Isolator.

Ma per quanto riguarda la scrittura di unit test per il codice appena scritto? È una buona pratica utilizzare un framework non vincolato in tale scenario? Oppure un framework vincolato (come NSubstitute) impone una migliore progettazione del software?

Aggiornamento: Un framework non vincolato è un framework in grado di simulare quasi tutto, comprese le classi statiche, i costruttori statici e i metodi statici. Rendono possibile ad esempio falsificare il risultato di DateTime.Now.

unit-testing .net mocking

posta Ilya Suzdalnitski 08.05.2015 - 09:17

fonte

1 risposta

Leggi altre domande sui tag unit-testing .net mocking

Best practice per i parametri nelle API asincrone in Java Algoritmo di visualizzazione del grafico

score 1 · Accepted Answer

Spetta a te decidere se è necessario utilizzare un framework di test delle unità. Qualsiasi dipendenza dovrà essere simulata in modo tale che la logica possa essere testata separatamente. Con un codice legacy in cui le dipendenze non sono visibili, un framework di simulazione o simulazione può aiutare a esporre tali dipendenze e sostituirle in modo da poter testare facilmente quel codice senza importanti refactoring.

Nello sviluppo nuovo / greenfield, non si può certamente usare una struttura di derisione se tutte le dipendenze sono esposte. Ciò significa che lo sviluppatore è responsabile della scrittura di tutti i mock invece del framework che li genera per te. Potresti decidere che è più semplice lasciare che il framework in linea quelle dipendenze anziché il team che scrive manualmente i falsi / falsi.

Se non si desidera utilizzare un framework, ad esempio considerare il calcolo di un'età. Questo può anche rispondere alla domanda @Greg B, perché dovresti prendere in giro DateTime.Now . Ha bisogno del tempo corrente per calcolare l'età che sarà difficile da produrre risultati di test coerenti da quando l'ora corrente cambia.

Interfaccia

public interface IClock
{
    DateTime Now { get; }
}

Implementazione reale

public class SystemClock : IClock
{
    public DateTime Now { get { return DateTime.Now; } }
}

Class

public class DateLogic
{
    private readonly IClock _clock;

    public DateLogic(IClock clock)
    {
        _clock = clock;
    }
    public int CalculateAge(DateTime dateOfBirth)
    {
        DateTime now = _clock.Now;

        int age = now.Year - dateOfBirth.Year;
        if (now < dateOfBirth.AddYears(age)) age--;

        return age;
    }
}

Orologio falso / falso

 public class MockClock200011 : IClock
    {
        public DateTime Now {get {return new DateTime(2000,1,1); } }
    }

Test

[TestMethod]
    public void TestCalculateAge()
    {
        var expected = 30;
        DateTime birthday = new DateTime(1969, 9, 11);
        IClock clock = new MockClock200011();
        var dateLogic = new DateLogic(clock);

        var actual = dateLogic.CalculateAge(birthday);

        Assert.AreEqual(expected, actual);
    }

Quindi, in questo caso, abbiamo scritto la nostra simulazione personale invece di fare il framework e abbiamo messo il calcolo della nostra età in isolamento. Non importa quale anno / ora, il test produrrà gli stessi risultati. Non vedo alcun contro di usare un framework oltre al costo e una dipendenza da quel software. Come si può vedere, è possibile cavarsela senza che le dipendenze vengano esposte per implementazioni simulate / finte.