Utilizzo di asserzioni personalizzate nei test delle unità

Question

Utilizzo di asserzioni personalizzate nei test delle unità

#1 da (6 voti)
#2 da (0 voti)

3

Ho chiesto una domanda qui sopra e Laiv ha condiviso il seguente www.gridshore.nl/2009/07/29/domain-driven-design-and-the-equals-method/">link.

Nell'articolo; si afferma che Eric Evans evita i metodi .equals sulle Entità.

In questo questione; il rispondente accettato parla dell'utilizzo di asserzioni personalizzate per il test unitario piuttosto che .equals

Pertanto, sto osservando le affermazioni personalizzate. Ho creato la seguente classe, che confronta due prodotti:

public static bool IsSameDescription(Product product1, Product product2)
        {
            // Check for null values and compare run-time types.
            if (product1 == null || product2==null)
                return false;

            return (product1.description == product2.description);
        }

Quindi posso farlo nel Test unità:

Assert.AreEqual(expectedProduct, actualProduct);

Che cosa voglio confrontare due elenchi di prodotti? Potrei usare un metodo .equals e poi fare questo:

CollectionAssert.AreEqual(expectedProductList, actualProductList);

Come potrei implementarlo? Potrei implementare una funzione statica che accetta due elenchi e li confronta. Tuttavia, CollectionAssert non lo userebbe? Lo farebbe? (perché usa .equals dietro le quinte) Come posso fare questo?

unit-testing c# domain-driven-design

posta w0051977 17.08.2017 - 15:28

fonte

2 risposte

0

Come alternativa FluentAssertions la libreria dispone di numerosi metodi di asserzione e possibilità di configurarli in modo leggibile.

Nel tuo caso particolare, è possibile utilizzare il metodo ShouldAllBeEquivalentTo

var expectedProducts = new[]
{
    new Product { Id = 1, Description = "One" },
    new Product { Id = 2, Description = "Two" }
}

var actualProducts = classUnderTest.CreateProducts();

actualProducts.ShouldAllBeEquivalent(
     expectedProducts, 
     config => config.Including(product => product.Description));

ShouldAllBeEquivalent asserirà che la raccolta actual contiene gli stessi prodotti della raccolta expected , dove l'uguaglianza sarà asserita solo dalla proprietà Description .

risposta data 26.08.2017 - 12:38

fonte

Leggi altre domande sui tag unit-testing c# domain-driven-design

Gestione delle risorse collegate nell'interfaccia utente Posto migliore per convertire un oggetto in un altro oggetto

score 6 · Accepted Answer

Per applicare lo stesso metodo a una raccolta, puoi usare LINQ con grande efficacia.

Se vuoi confrontare tutto con la stessa istanza puoi farlo:

productList.Select(item => IsSameDescription(productA, item)).ToList();

Anche il CollectionAssert ha una variante che accetta una funzione comparatore :

CollectionAssert(expectedProductList, actualProductList, IsSameDescription);

Informazioni sulle eccezioni personalizzate:

Il motivo principale per utilizzare le asserzioni personalizzate anziché il generico AssertTrue o Assert.IsTrue è che i messaggi di errore forniscono maggiori dettagli su quale fosse esattamente il problema. Ad esempio, Assert.AreEqual(obj1, obj2) o Assert.That(obj1).IsEqualTo(obj2) ti diranno sia la risposta prevista che il valore effettivo. Questo dovrebbe essere l'obiettivo che stai cercando con qualsiasi affermazione personalizzata.

Ci sono diverse librerie di asserzioni, quindi potresti dover reinventare la ruota. Alcune librerie di test includono la libreria delle asserzioni (come NUnit, JUnit, ecc.).

Preferisco di gran lunga vedere l'uso intelligente di una libreria di asserzioni standard piuttosto che scrivere asserzioni personalizzate per tutto. Usando l'esempio che hai fornito:

Assert.AreEqual(product1.Description, product2.Description);

È tanto espressivo quanto necessario.