Assert areequal c что это

Не пойму как работает Assert.AreEqual

Помогите разобраться, по отдельности все работает и считает, а вот с классом NumberTest не могу сконектить чтоб работало, выдает ошибку.
Задание заключается в том, чтобы сложить все цифры числа, например 123 => 1+ 2+ 3 = 6

Есть вот такой класс

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

[TestFixture] public class NumberTest { private Number num; [SetUp] public void SetUp() { num = new Number(); } [TearDown] public void TearDown() { num = null; } [Test] public void Tests() { Assert.AreEqual(7, num.DigitalRoot(16)); Assert.AreEqual(6, num.DigitalRoot(456)); } } public class Number { public int DigitalRoot(long n) { long sum = 0; if (n  10) return Convert.ToInt32(n); while (n >= 10) { sum += (n % 10); n = n / 10; } sum += n; if (sum  10) return Convert.ToInt32(sum); else return DigitalRoot(sum); } } class Program { static void Main(string[] args) { NumberTest number = new NumberTest(); number.SetUp(); number.TearDown(); number.Tests(); } }

Лучшие ответы ( 1 )
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:

CollectionAssert.AreEqual(). Как сравниваются коллекции элементов своего типа?
Как сравниваются коллекции элементов своего типа(далее объект данного класса element)? Используется.

Не пойму, как работает.
Закончились идеи, как работает программа. Ничего не выходит. Помогите, если нетрудно Дана.

Не пойму как работает
В учебнике дан пример рекурсии. Вывод цифр целого положительного числа в обратном порядке: var.

Не пойму как работает While
n = 4 a = 1 i = 0 summa = 0 while i < n: summa += a a = a/-2 i += 1 # print(summa)

Администратор

Эксперт .NET

16392 / 12871 / 5072
Регистрация: 17.03.2014
Сообщений: 26,183
Записей в блоге: 1

YMZ, Assert.AreEqual всего-лишь сравнивает переданные значения. Проблема кроется не в нем, а в следующем участке кода

46 47 48

number.SetUp(); number.TearDown(); number.Tests();

В чем разница между Assert.AreEqual и Assert.Equals C#?

Assert — это обычный класс, который, как и все классы .NET, наследуют от System.Object . Assert.Equals – это просто наследуемый метод Object.Equals .

Asser.AreEquals – это метод класса Assert , который выкидывает AssertFailedException если два объекта не равны. Это штатный способ проверять утверждение о равенстве двух объектов.

В версии TestFramework 14.0.0.X Assert.Equals перекрыт, и выкидывает исключение, что бы избежать путаницы и не вводить никого в заблуждение. Внутри написано что-то такое:

/// Static equals overloads are used for comparing instances of two types for reference /// equality. This method should not be used for comparison of two instances for /// equality. This object will always throw with Assert.Fail. Please use /// Assert.AreEqual and associated overloads in your unit tests. public new static bool Equals(object objA, object objB)

ClassicAssert.AreEqual

ClassicAssert.AreEqual tests whether the two arguments are equal.

ClassicAssert.AreEqual(double expected, double actual, double tolerance); ClassicAssert.AreEqual(double expected, double actual, double tolerance, string message, params object[] params); ClassicAssert.AreEqual(object expected, object actual); ClassicAssert.AreEqual(object expected, object actual, string message, params object[] params);

Comparing Numerics of Different Types

The method overloads that compare two objects make special provision so that numeric values of different types compare as expected. This assert succeeds:

ClassicAssert.AreEqual(5, 5.0);

Comparing Floating Point Values

Values of type float and double are compared using an additional argument that indicates a tolerance within which they will be considered as equal.

Special values are handled so that the following Asserts succeed:

ClassicAssert.AreEqual(double.PositiveInfinity, double.PositiveInfinity); ClassicAssert.AreEqual(double.NegativeInfinity, double.NegativeInfinity); ClassicAssert.AreEqual(double.NaN, double.NaN);

Comparing Arrays and Collections

NUnit is able to compare single-dimensioned arrays, multi-dimensioned arrays, nested arrays (arrays of arrays) and collections. Two arrays or collections are considered equal if they have the same dimensions and if each pair of corresponding elements is equal.

NUnit 3.0 adds the ability to compare generic collections and dictionaries.

Assert-сообщения в тестах

В этом посте мы поговорим о том, должны ли вы использовать Assert-сообщения в ваших тестах.

Я получил интересный вопрос от коллеги читателя, на котором хотел бы остановиться поподробнее:

У меня вопрос по поводу Assert-сообщений: следует ли использовать перегрузку, содержащую параметр сообщения, и использовать ее для передачи строки, описывающей причину неудачи Assert (также “Утверждения”)?

Ответ на этот вопрос сводится к двум аспектам:

Читаемость теста — насколько легко понять, что делает тест.
Простота диагностики — насколько легко понять, почему тест не пройден.

Читаемость теста

Люди часто используют Assert-сообщения, чтобы помочь членам команды и самим себе в будущем понять, что происходит в тесте. Давайте рассмотрим следующий пример:

[Test] public void Hiring_a_new_team_member() < var company = new Company(); var person = new Person(UserType.Customer); company.HireNewMember(person); Assert.AreEqual(UserType.Employee, person.Type); // нет сообщения Assert.AreEqual(1, company.NumberOfEmployees); // нет сообщения >

Вместо голого Assert вы также можете указать причину, по которой тестовый Assert что-либо валидирует:

[Test] public void Hiring_a_new_team_member()

Такие утверждения помогают, но они имеют свою цену. Эти сообщения требуют от вас

Потратить время на их написание
Поддерживать их продвижение вперед

Вводите assert-сообщения только тогда, когда это абсолютно необходимо — когда вы не можете улучшить читаемость теста каким-либо другим способом. Но даже тогда, склоняйтесь к выбору не писать их.

Самый простой способ получить быстрый выигрыш в читаемости теста — это переключиться на удобочитаемую запись утверждений. Например, NUnit имеет специальную модель утверждений на основе ограничений (constraint), которая помогает вам писать свои утверждения следующим образом:

[Test] public void Hiring_a_new_team_member()

Или вы можете использовать мои любимые Fluent Assertions:

[Test] public void Hiring_a_new_team_member()

Такие утверждения читаются на простом английском языке — именно так, как вы хотели бы, чтобы читался весь ваш код. Мы, люди, предпочитаем воспринимать информацию в форме историй. Все истории придерживаются данной модели:

[Субъект] [действие] [объект].

Боб открыл дверь.

Здесь Боб — субъект, открыл — действие, а дверь — объект. То же самое относится и к коду.

company.NumberOfEmployees.Should().Be(1);

читает лучше чем

Assert.AreEqual(1, company.NumberOfEmployees);

именно потому, что здесь прослеживается история.

Кстати, парадигма ООП стала успешной отчасти благодаря удобству чтения. С ООП вы также можете структурировать код так, чтобы он читался как история.

Простота диагностики

Другой взгляд на assert-сообщения — с точки зрения простоты диагностики. Другими словами, простота понимания причины провала теста без изучения кода этого теста. Это полезно при чтении результатов сборки CI.

С точки зрения диагностики, следуйте данному руководству: если вы можете легко повторно запустить тест локально, этот тест не нуждается в assert-сообщении. Это верно для всех модульных тестов (поскольку они не работают с внепроцессными зависимостями), но в меньшей степени для интеграционных и сквозных тестов.

Пирамида тестирования

По мере того, как вы будете подниматься выше в тестовой пирамиде, вам может понадобиться более подробная информация, потому что интеграционные (и особенно сквозные) тесты медленнее и возможно вы не сможете их повторно запускать по желанию.

Но даже с интеграцией и сквозными тестами существуют способы облегчить диагностику, не прибегая к assert-сообщениям:

Сделайте так, чтобы тест проверял один модуль поведения — когда тест проверяет что-то одно, часто легко определить, что пошло не так. (Это не всегда применимо к сквозным тестам, так как вы можете захотеть, чтобы такие тесты проверяли, как несколько единиц поведения работают вплотную).
Именуйте свои модульные тесты соответственно — Идеальное имя теста описывает поведение приложения в бизнес-терминах, так что даже непрограммист может его понять.

Например, ошибка в следующем утверждении:

person.Type.Should().Be(UserType.Employee);

выдает следующее сообщение об ошибке:

Xunit.Sdk.EqualException: Assert.Equal() Failure Expected: Employee Actual: Customer

Комбинация таких генерируемых средой сообщений и понятных человеку имен тестов делает 90% пользовательских assert-сообщений бесполезными даже с точки зрения простоты диагностики. Единственное исключение — это длительные сквозные тесты. Они часто содержат многоэтапные проверки, поэтому имеет смысл использовать дополнительные assert-сообщения, чтобы понять, какой из шагов не удался. Однако таких сквозных тестов не должно быть много.

Конечно, чтобы воспользоваться сгенерированными фреймворком сообщениями о сбоях, вам нужно избегать общих булевых сравнений, таких как:

(person.Type == UserType.Employee).Should().BeTrue();

Потому что они приводят к следующему сообщению об ошибке:

Xunit.Sdk.TrueException: Assert.True() Failure Expected: True Actual: False

Что не помогает с диагностикой вообще.

Резюме

Вы часто ощущаете лень, когда речь идет о написании утверждений? Что ж, теперь вы можете оправдать ее и отослать своих коллег к этой статье.

«Я рад, что у этого есть название»

Шутки в сторону, однако, вот резюме:

Существует два аспекта использования assert-сообщений:
- Читаемость теста (насколько легко понять, что делает тест).
- Простота диагностики (насколько легко понять, почему тест не проходится во время сборки CI).
- Проверка тестом одного модуля поведения
- Именование тестов в бизнес терминах
Похожие публикации: