Правильное использование Assert
От: _NN_ www.nemerleweb.com
Дата: 15.05.20 08:09
Оценка:
В NUnit порядок expected, actual , а не не наоборот.
В CodeJam частенько вижу неправильный порядок использования.
Например:

AreEqual(range.ToInvariantString(), "[2..9]: { 'Key1':[2..2]; 'Key2':[5..7); 'Key2':(8..9] }");
AreEqual(
    range.SubRanges.Select(r => r.Key).Distinct().Join(";"),
    "Key1;Key2");


Как вариант можно перейти на использование Fluent assertion syntax с Assert.That и тогда не будет таких ошибок.
Другой вариант использовать Fluent Assertions, которые умеют работать поверх любого тестового фреймворка.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re: Правильное использование Assert
От: Sinix  
Дата: 15.05.20 08:22
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>В NUnit порядок expected, actual , а не не наоборот.

_NN>В CodeJam частенько вижу неправильный порядок использования.

Это проблемы NUnit.
В шарпе принято использовать прямоя порядок аргументов при сравнении,
if (x == 2) {}
// не
if (2 == x) {}

В самом NUnit, кстати, в основном тоже прямой порядок (см Assert.That(), Assert.GreaterThan() etc).
Из двух вариантов "сохраняем общий стиль по всему коду" и "прогинаемся под конкретную библиотеку" мне больше нравится первый.


_NN>Как вариант можно перейти на использование Fluent assertion syntax с Assert.That и тогда не будет таких ошибок.

Тогда уж на fluent assertions сразу. Но кто это будет делать, и, главное, зачем?

Код в библиотеке довольно стабилен и значительных правок не предвидится, необходимости нет.
Так что тратить время на тесты можно только по принципу "когда больше заняться нечем".
Я тесты точно менять пока не буду. У нас огромный техдолг по документации, надо сначала его разгрести.
Re[2]: Правильное использование Assert
От: _NN_ www.nemerleweb.com
Дата: 15.05.20 08:37
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, _NN_, Вы писали:


_NN>>В NUnit порядок expected, actual , а не не наоборот.

_NN>>В CodeJam частенько вижу неправильный порядок использования.

S>Это проблемы NUnit.

S>В шарпе принято использовать прямоя порядок аргументов при сравнении,
S>
S>if (x == 2) {}
S>// не
S>if (2 == x) {}
S>

S>В самом NUnit, кстати, в основном тоже прямой порядок (см Assert.That(), Assert.GreaterThan() etc).
Это если использовать везде Assert.That, а в коде тестов он не используется.

S>Из двух вариантов "сохраняем общий стиль по всему коду" и "прогинаемся под конкретную библиотеку" мне больше нравится первый.

Это упрощает поиск ошибок.
Видим, что ожидали и что получили и ясно, что к чему.

_NN>>Как вариант можно перейти на использование Fluent assertion syntax с Assert.That и тогда не будет таких ошибок.

S>Тогда уж на fluent assertions сразу. Но кто это будет делать, и, главное, зачем?
Есть хорошие аргументы чем это лучше Assert.That от NUnit ?
Я тут на работе подумываю использовать, но что-то не уверен.

S>Код в библиотеке довольно стабилен и значительных правок не предвидится, необходимости нет.

S>Так что тратить время на тесты можно только по принципу "когда больше заняться нечем".
S>Я тесты точно менять пока не буду. У нас огромный техдолг по документации, надо сначала его разгрести.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[3]: Правильное использование Assert
От: Sinix  
Дата: 15.05.20 08:57
Оценка:
Здравствуйте, _NN_, Вы писали:

S>>В самом NUnit, кстати, в основном тоже прямой порядок (см Assert.That(), Assert.GreaterThan() etc).

_NN>Это если использовать везде Assert.That, а в коде тестов он не используется.
Тут про другое речь. Если сама библиотека не соблюдает один стиль — почему мы должны заморачиваться?


S>>Из двух вариантов "сохраняем общий стиль по всему коду" и "прогинаемся под конкретную библиотеку" мне больше нравится первый.

_NN>Это упрощает поиск ошибок.
_NN>Видим, что ожидали и что получили и ясно, что к чему.
I don't care, если честно. Если тест сломался — его всё равно надо сначала воспроизвести под отладчиком, найти ошибку, поправить и прогнать ешё раз.
Наличие понятного сообщения никак не ускоряет этот процесс, т.е. особой ценности не имеет.


S>>Тогда уж на fluent assertions сразу. Но кто это будет делать, и, главное, зачем?

_NN>Есть хорошие аргументы чем это лучше Assert.That от NUnit ?

Fluent assertions сразу понятные сообщения выдают без лишнего кода с нашей стороны. И выполнены все в одном стиле.
Лично мне очень зашли.

Единственно, у них нет удобного синтаксиса для .Throws<>/DoesNotThrow<>, но это решается хелпером или методами из NUnit.
Re[4]: Правильное использование Assert
От: _NN_ www.nemerleweb.com
Дата: 15.05.20 09:25
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, _NN_, Вы писали:


S>>>В самом NUnit, кстати, в основном тоже прямой порядок (см Assert.That(), Assert.GreaterThan() etc).

_NN>>Это если использовать везде Assert.That, а в коде тестов он не используется.
S>Тут про другое речь. Если сама библиотека не соблюдает один стиль — почему мы должны заморачиваться?

Как раз внутри библиотеки всё в стиле Assert.That, но если сломают совместимость никто пользоваться не будет

S>>>Из двух вариантов "сохраняем общий стиль по всему коду" и "прогинаемся под конкретную библиотеку" мне больше нравится первый.

_NN>>Это упрощает поиск ошибок.
_NN>>Видим, что ожидали и что получили и ясно, что к чему.
S>I don't care, если честно. Если тест сломался — его всё равно надо сначала воспроизвести под отладчиком, найти ошибку, поправить и прогнать ешё раз.
S>Наличие понятного сообщения никак не ускоряет этот процесс, т.е. особой ценности не имеет.
Кому как.
Мне частенько упрощает когда есть код вида AreEqual(a, b) , легко понять что откуда пришло.

S>>>Тогда уж на fluent assertions сразу. Но кто это будет делать, и, главное, зачем?

_NN>>Есть хорошие аргументы чем это лучше Assert.That от NUnit ?

S>Fluent assertions сразу понятные сообщения выдают без лишнего кода с нашей стороны. И выполнены все в одном стиле.

S>Лично мне очень зашли.

S>Единственно, у них нет удобного синтаксиса для .Throws<>/DoesNotThrow<>, но это решается хелпером или методами из NUnit.

Ну это наверное надо просто пуло реквестор предложить

В Nunit ещё есть ещё ассерты для проверки файлов Does.Exist и DirectoryAssert .

У нас в проекте тоже коллеги путают порядок и это вполне очевидно, а постоянный Assert.That напрягает слегка.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[4]: Правильное использование Assert
От: _NN_ www.nemerleweb.com
Дата: 13.06.20 11:54
Оценка:
Здравствуйте, Sinix, Вы писали:

S>>>Из двух вариантов "сохраняем общий стиль по всему коду" и "прогинаемся под конкретную библиотеку" мне больше нравится первый.

_NN>>Это упрощает поиск ошибок.
_NN>>Видим, что ожидали и что получили и ясно, что к чему.
S>I don't care, если честно. Если тест сломался — его всё равно надо сначала воспроизвести под отладчиком, найти ошибку, поправить и прогнать ешё раз.
S>Наличие понятного сообщения никак не ускоряет этот процесс, т.е. особой ценности не имеет.
Кому как
Меня вот очень выручает в проекте.

S>Fluent assertions сразу понятные сообщения выдают без лишнего кода с нашей стороны. И выполнены все в одном стиле.

S>Лично мне очень зашли.

S>Единственно, у них нет удобного синтаксиса для .Throws<>/DoesNotThrow<>, но это решается хелпером или методами из NUnit.


Не оно ?
https://fluentassertions.com/exceptions/

subject.Invoking(y => y.Foo("Hello"))
    .Should().Throw<InvalidOperationException>();

Func<Task> act = async () => { await asyncObject.ThrowAsync<ArgumentException>(); };
act.Should().NotThrow();


Как вариант можно тогда и на xUnit перейти, благо у них поддержка C# nullable уже включена.
Хотя не уверен, что есть смысл.
http://rsdn.nemerleweb.com
http://nemerleweb.com
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.