c# - test - ¿Cómo implementar el mensaje de alerta descriptivo de XUnit?

xunit vs nunit

Question

Contexto

en XUnit github, encontré esto: Agregar Assert.Equal (mensaje esperado, real) sobrecarga # 350 (por lo que un desarrollador solicita una sobrecarga no existente, ver más abajo)

Cita de la respuesta:

Somos creyentes en el código de auto-documentación; Eso incluye tus aserciones.

(por lo que el equipo de XUnit lo rechaza)

Ok ya lo tengo También creo que el código auto documentado. Todavía no puedo encontrar este caso de uso:

Muestra

// Arrange
// Create some external soap service client and its wrapper classes

// Act
// client.SomeMethod();

// Assert
// Sorry, soap service''s interface, behaviour and design is *given*
// So I have to check if there is no Error, and 
// conveniently if there is, then I would like to see it in the assertion message

Assert.Equal(0, client.ErrorMessage.Length); // Means no error

// I would like to have the same result what would be the following *N*U*n*i*t* assert:
// Assert.AreEqual(0, client.ErrorMessage.Length, client.ErrorMessage); // Means no error

Pregunta

¿Cómo puedo implementar un mensaje de afirmación descriptivo en este caso en XUnit que todavía no tiene tal sobrecarga?

Answer 1

Utilice las sugerencias proporcionadas en el enlace. Al igual que afirmaciones fluidas o crear su propia aserción que envuelve el Assert.True or Assert.False que se quedaron con sus sobrecargas de mensajes. Fue mencionado más abajo

Quote

Puede proporcionar mensajes a Assert.True y .False. Si simplemente no puede vivir sin mensajes (y se niega a usar una aseveración diferente), siempre puede recurrir a:

Assert.True(number == 2, "This is my message");

Quote:

Si realmente desea tener mensajes, puede agregar xbehave Assertions o tal vez xbehave a sus proyectos de prueba y usar su sintaxis. Afirmaciones fluidas incluso arroja excepciones xunit.net si encuentra su presencia.

Answer 2

Yo estaba teniendo el mismo problema. Tengo una prueba que extrae datos de dos API web y luego compara y afirma varias cosas sobre el contenido. Comencé a usar aseveraciones estándar de XUnit como:

Assert.Equal(HttpStatusCode.OK, response1.StatusCode);
Assert.Equal(HttpStatusCode.OK, response2.StatusCode);

Pero mientras esto da un mensaje útil de que se ha devuelto un 404, no se borra de los registros en nuestro servidor de compilación / CI, cuyo servicio causó el mensaje de error.

Terminé agregando mi propia afirmación para dar contexto:

public class MyEqualException : Xunit.Sdk.EqualException
{
    public MyEqualException(object expected, object actual, string userMessage)
        : base(expected, actual)
    {
        UserMessage = userMessage;
    }

    public override string Message => UserMessage + "/n" + base.Message;
}

public static class AssertX
{
    /// <summary>
    /// Verifies that two objects are equal, using a default comparer.
    /// </summary>
    /// <typeparam name="T">The type of the objects to be compared</typeparam>
    /// <param name="expected">The expected value</param>
    /// <param name="actual">The value to be compared against</param>
    /// <param name="userMessage">Message to show in the error</param>
    /// <exception cref="MyEqualException">Thrown when the objects are not equal</exception>
    public static void Equal<T>(T expected, T actual, string userMessage)
    {
        bool areEqual;

        if (expected == null || actual == null)
        {
            // If either null, equal only if both null
            areEqual = (expected == null && actual == null);
        }
        else
        {
            // expected is not null - so safe to call .Equals()
            areEqual = expected.Equals(actual);
        }

        if (!areEqual)
        {
            throw new MyEqualException(expected, actual, userMessage);
        }
    }
}

Entonces puedo hacer las mismas afirmaciones que:

AssertX.Equal(HttpStatusCode.OK, response1.StatusCode, $"Fetching {Uri1}");
AssertX.Equal(HttpStatusCode.OK, response2.StatusCode, $"Fetching {Uri2}");

y el registro de errores proporciona el mensaje real, esperado y previo a mi mensaje sobre qué webapi fue el culpable.

Me doy cuenta de que llego tarde para responder, pero pensé que esto podría ayudar a otros a buscar una solución práctica que no tenga tiempo para instalar / aprender otro marco de prueba solo para obtener información útil de los fallos de prueba.