Какие инструменты и методы вы использовали для ассертов (Assert) в тестировании?

Ну вот, опять про эти ваши тесты на C#. Слушай, я тебе как старый пердун, который уже дохуя этих тестов написал, расскажу. Все эти NUnit и xUnit — они, в принципе, одно и то же, только в профиль. Как две сиськи у одной бабы, понимаешь? Суть одна, а названия разные.

Так вот, сидишь ты, пишешь свой код, и тут надо проверить, не накосячил ли ты где. Берёшь их родной класс Assert и начинаешь долбить. Самые ходовые штуки:

• Сравнил и обосрался? Assert.AreEqual (в NUnit) или Assert.Equal (в xUnit). По сути, одно и то же — ты ожидаешь одно, а получаешь другое, и тест падает, как пьяный мужик с лавочки.

  // NUnit
  Assert.AreEqual(expectedValue, actualValue); // Ждём 5, а получили 3. Пиздец, тест не прошёл.
  // xUnit
  Assert.Equal(expectedValue, actualValue); // Та же хуйня, только в другом фраме.

• Правда или ложь? Assert.IsTrue / Assert.IsFalse. Типа, «эй, чувак, это правда?». Если нет — получай по ебалу от системы сборки.

  Assert.IsTrue(result.IsSuccessful); // Если не успешно — иди нахуй, всё сломал.

• А не вылетит ли? Assert.Throws. Вот это полезная штука, когда ты специально вызываешь говно, чтобы проверить, как код от него чихает. Поймал исключение — молодец, не поймал — опять обосрался.

  var exception = Assert.Throws<InvalidOperationException>(() => service.PerformInvalidAction());
  Assert.AreEqual("Expected error message", exception.Message); // И текст ошибки должен совпасть, а то мало ли!

• А есть ли что? Assert.IsNull / Assert.IsNotNull. Проверка на пустоту. Пришёл null, а ты его не ждал — опять пизда тесту.
• И в куче тоже. Assert.Contains — ищешь иголку в стоге сена. Нашёл — хорошо, не нашёл — сам понимаешь.

Но вот, блядь, есть одна проблема. Читать эти все Assert.AreEqual( ожидаемое, полученное, "сообщение об ошибке какое-то ёбаное") — это же глаза сломать можно! Тут на сцену выходит Fluent Assertions. Это такая библиотека, которая позволяет писать проверки, как будто ты предложения строишь. Красиво, чётко, и даже какой-нибудь новичок поймёт, что тут происходит.

Смотри, как можно:

actualResult.Should()
    .Be(expectedResult)    // Должно быть равно
    .And.BeGreaterThan(0)  // И больше нуля
    .And.NotBeNull();      // И не пустое, блядь!

Прям песня, а не код. Сразу видно, что от чего зависит.

Так что выбор, епта, простой. Если тебе и команде похуй на читаемость, лишь бы работало — юзай стандартный Assert, он встроенный, лишних зависимостей нет. А если хочется, чтобы тесты читались как утренняя газета, даже через полгода, — бери Fluent Assertions. Но будь готов, что какой-нибудь консервативный тимлид посмотрит на это и скажет: «Нахуя нам эта ваша плавучая хрень?». Так что советуйся с командой, а то сам останешься крайним.