¿Cuál es la forma idiomática de verificar el tamaño de la colección en xUnit?


112

Tengo en mi suite de pruebas una prueba que es algo como esto:

[Fact]
public void VerifySomeStuff()
{
    var stuffCollection = GetSomeStuff();

    Assert.Equal(1, stuffCollection.Count());
}

Esta prueba funciona como esperaba, pero cuando la ejecuto, xUnit imprime una advertencia:

advertencia xUnit2013: No use Assert.Equal () para verificar el tamaño de la colección.

Sin embargo, no se sugiere ninguna alternativa en la advertencia, y una búsqueda en Google me lleva al código fuente en xUnit para la prueba que verifica que esta advertencia esté impresa.

Si Assert.Equal()no es la forma correcta de verificar la longitud de una colección, ¿cuál es?


Para aclarar: me doy cuenta de que podría "engañar" a xUnit para que no emita esta advertencia, por ejemplo, extrayendo una variable o usando en su Assert.True(stuff.Count() == 1)lugar. El último es simplemente hacky, y el primero parece que si xUnit está, por ejemplo, tratando de evitar múltiples iteraciones de un IEnumerable<T>, entonces este es el camino equivocado (porque obtendré sugerencias del compilador sobre eso por separado si es un problema), y xUnit en sí mismo nunca debería tener que evaluar la entrada más de una vez (de hecho, probablemente obtendrá la misma entrada independientemente de la extracción de la variable, debido a cómo funciona la llamada a la función C #).

Entonces, no solo estoy interesado en eliminar esa advertencia de mi salida. Una respuesta a mi pregunta también explica por qué esa advertencia está incluida en la biblioteca en primer lugar y por qué cualquier enfoque que deba usar es mejor.


si almacena stuffCollection.Count()en una variable separada y la pasa a la aserción, ¿le da el mismo error?
hellyale

¿Quizás este ?
Uwe Keim

Respuestas:


112

Xunit ofrece soluciones rápidas para la mayoría de sus advertencias, por lo que debería poder ver lo que cree que es "correcto".

xunit

En su caso, quiere que use Assert.Singleya que espera exactamente un artículo. Si estuviera afirmando un número arbitrario, como 412, entonces no le daría una advertencia sobre el uso Count. Solo sugerirá el uso Singlesi está esperando un artículo o Emptysi no espera ningún artículo.


6
Gracias, eso tiene sentido. FWIW, estaba viendo esto al compilar en VS Code, donde la acción rápida no apareció, por lo que incluir la sugerencia de corrección en el mensaje de advertencia habría sido mucho más útil.
Tomas Aschan

2
@TomasLycken - ah. Sí, hay un problema para eso aquí: github.com/xunit/xunit/issues/1423
vcsjones

5
No soy fanático de ese comportamiento; a veces el conteo 1 es solo incidental y parece menos expresivo hacer cumplir la llamada a .Single (). La prueba puede cambiar para esperar un recuento diferente, y parece molesto tener que hacer el cambio para llamar a un método completamente diferente en lugar de simplemente cambiar un número.
vargonian

2
Single es genial para un solo elemento, tengo 3 elementos y no quiero escribir Assert.Collection completo, ¿xUnit tiene Assert.Triple? jaja
Pawel Cioch

1
@PawelCioch acuerdo con xunit.net/xunit.analyzers/rules/xUnit2013.html tienen Empty, Singley NotEmpty- si se espera un valor dinámico xUnit2013 no deben dar lugar.
mbx

2

Encontré que esto me da el mismo error:

Assert.Equal(2, vm.Errors.Count());

Y emitirlo evitó que apareciera el error.

Assert.Equal(2, (int)vm.Errors.Count());

2
Estoy bastante seguro de que esta no es la forma ideomática .
mbx

1

Para un solo elemento en una lista, es mejor usar esto en su lugar: Assert.Single(resultList);


-1

Tuve el mismo problema cuando usé la propiedad Count como se muestra a continuación en xUnit.

ingrese la descripción de la imagen aquí

Después, uso la función Count () en la colección, solucionó mi problema.


Se solucionó el problema, ¡pero aún no usas XUnit como deberías!
Daniel Eisenreich

8
@DanielEisenreich ¿cuál es la forma correcta de afirmar el recuento de un número específico si es mayor que 1?
SomeGuyOnAComputer

@SomeGuyOnAComputer y los otros 4 votos a favor. Olvida lo que dije, fui demasiado descarado. Si es más grande, no tienes otra opción.
Daniel Eisenreich
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.