Contexte
dans github XUnit, j'ai trouvé ceci: Ajouter Assert.Equal (attendu, réel, message) surcharge # 35 (donc un développeur demande une surcharge non existante voir ci-dessous)
Citation de la réponse:
Nous croyons au code auto-documenté; cela inclut vos affirmations.
(donc l'équipe XUnit le rejette)
OK j'ai compris. Je crois aussi au code auto-documenté. Je ne peux toujours pas découvrir ce cas d'utilisation:
Échantillon
// 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
Question
Comment puis-je implémenter un message d'assertion descriptif dans ce cas dans XUnit qui n'a toujours pas une telle surcharge?
Utilisez les suggestions fournies sur le lien. Comme assertions fluides ou créez votre propre assertion qui enveloppe le Assert.True or Assert.False
qui se sont retrouvés avec leurs surcharges de messages. Il a été mentionné plus bas
Vous pouvez fournir des messages à Assert.True et .False. Si vous ne pouvez tout simplement pas vivre sans messages (et refusez d'utiliser une assertion différente), vous pouvez toujours vous rabattre sur:
Assert.True(number == 2, "This is my message");
Si vous voulez vraiment avoir des messages, vous pouvez ajouter Assertions fluides ou peut-être xbehave à vos projets de test et utiliser leur syntaxe. Fluent Assertions lève même des exceptions xunit.net s'il rencontre sa présence.
J'avais le même problème. J'ai un test qui extrait les données de deux API Web, puis compare et affirme diverses choses sur le contenu. J'ai commencé à utiliser des assertions XUnit standard comme:
Assert.Equal(HttpStatusCode.OK, response1.StatusCode);
Assert.Equal(HttpStatusCode.OK, response2.StatusCode);
Mais bien que cela donne un message utile qu'un 404 a été retourné, il ne ressort pas clairement des journaux de notre serveur build/CI quel service a provoqué le message d'erreur.
J'ai fini par ajouter ma propre affirmation pour donner un contexte:
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);
}
}
}
Ensuite, je peux faire les mêmes affirmations que:
AssertX.Equal(HttpStatusCode.OK, response1.StatusCode, $"Fetching {Uri1}");
AssertX.Equal(HttpStatusCode.OK, response2.StatusCode, $"Fetching {Uri2}");
et le journal des erreurs donne le réel, prévu et ajoute mon message sur quel webapi était le coupable.
Je me rends compte que je suis en retard pour répondre, mais j'ai pensé que cela pourrait aider les autres à rechercher une solution pratique qui n'a pas le temps d'installer/d'apprendre un autre cadre de test juste pour obtenir des informations utiles sur les échecs de test.