xUnit: asserisci che due List <T> sono uguali?


109

Sono nuovo di TDD e xUnit, quindi voglio testare il mio metodo che assomiglia a qualcosa del tipo:

List<T> DeleteElements<T>(this List<T> a, List<T> b);

Esiste un metodo Assert che posso utilizzare? Penso che qualcosa del genere sarebbe carino

List<int> values = new List<int>() { 1, 2, 3 };
List<int> expected = new List<int>() { 1 };
List<int> actual = values.DeleteElements(new List<int>() { 2, 3 });

Assert.Exact(expected, actual);

C'è qualcosa di simile?

Risposte:


137

xUnit.Net riconosce le raccolte quindi devi solo farlo

Assert.Equal(expected, actual); // Order is important

È possibile visualizzare altre asserzioni di raccolta disponibili in CollectionAsserts.cs

Per NUnit i metodi di confronto delle raccolte di librerie sono

CollectionAssert.AreEqual(IEnumerable, IEnumerable) // For sequences, order matters

e

CollectionAssert.AreEquivalent(IEnumerable, IEnumerable) // For sets, order doesn't matter

Maggiori dettagli qui: CollectionAssert

MbUnit ha anche asserzioni di raccolta simili a NUnit: Assert.Collections.cs


1
Collegamento al codice sorgente modificato per xunit.codeplex.com/SourceControl/changeset/view/…
Julien Roncaglia

1
Nuovo collegamento anche nei commenti interrotto.
Scott Stafford

1
Il progetto è ora spostato su GitHub, ma non sono stato in grado di trovare nemmeno quel particolare file sorgente lì.
MEMark

1
Per oggetti complessi non dimenticare che hai bisogno di un Equal + GetHasCode perché funzioni o di dare al metodo Equal un EqulityComparer personalizzato
maracuja-juice

2
Il metodo xUnit Equal restituisce false per due IEnumerables con contenuto uguale.
Vladimir Kocjancic,

31

Nella versione corrente di XUnit (1.5) puoi semplicemente usare

Assert.Equal (previsto, effettivo);

Il metodo precedente eseguirà un confronto elemento per elemento delle due liste. Non sono sicuro che funzioni per qualsiasi versione precedente.


8
Il problema che ho riscontrato con Assert.Equal for collections è che fallisce se gli elementi delle raccolte sono in ordini diversi, anche se gli elementi sono presenti in entrambi.
Scott Lawrence

1
@ ScottA.Lawrence Anche le liste hanno ordine! Ottieni lo stesso comportamento con HashSets?
johv

@johv non l'ho testato con HashSets, ma è una buona idea. Una volta che avrò avuto la possibilità di provarlo cercherò di ricordarmi di rispondere qui.
Scott Lawrence

2
Sembra anche fallire se i tipi di raccolta sono diversi, anche se contengono entrambi gli stessi elementi nello stesso ordine.
James White

3
Ma ha un risultato molto schifoso. Non ti dice DOVE differiscono due elenchi! :(
Zordid

17

Con xUnit, se desideri selezionare le proprietà di ciascun elemento da testare, puoi utilizzare Assert.Collection.

Assert.Collection(elements, 
  elem1 => Assert.Equal(expect1, elem1.SomeProperty),
  elem2 => { 
     Assert.Equal(expect2, elem2.SomeProperty);
     Assert.True(elem2.TrueProperty);
  });

Ciò verifica il conteggio previsto e garantisce che ogni azione venga verificata.


2

Recentemente, stavo usando xUnit 2.4.0e Moq 4.10.1pacchetti nella mia app asp.net core 2.2.

Nel mio caso sono riuscito a farlo funzionare con un processo in due passaggi:

  1. Definizione di un'implementazione di IEqualityComparer<T>

  2. Passa l'istanza di confronto come terzo parametro nel Assert.Truemetodo:

    Assert.True(expected, actual, new MyEqualityComparer());

Ma c'è un altro modo migliore per ottenere lo stesso risultato usando il pacchetto FluentAssertions . Ti permette di fare quanto segue:

// Assert          
expected.Should().BeEquivalentTo(actual));

È interessante notare che Assert.Equal()fallisce sempre anche quando ho ordinato gli elementi di due elenchi per ottenerli nello stesso ordine.


2
qualcosa non va con il tuo ordine BeEquivalentTo non si preoccupa dell'ordine (ecco perché il tuo test passa con BeEquivalentTo e non con assert.Equal)
RagnaRock
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.