23
Karma
16
Rating
Юрий Пастушенко @ypastushenko

.net разработчик, Dodo Pizza

Волшебная фея для юнит-тестов: DSL в C#

Волшебная фея для юнит-тестов: DSL в C#

0
  1. Не понял, почему не помогает? Ордер — это, кстати, не мок, а тестовые данные.


  2. Конкретно здесь Testable нужен только для того, чтобы завернуть в себя ассёрты на моках и создание самих моков. Protected методов тут нет.



Но, например для рефакторинга легаси можно его использовать и для вызова protected. Пользы будет больше чем зла.

Волшебная фея для юнит-тестов: DSL в C#

0

Можно ли накосячить при написании DSL? Да, разумеется.
Можно ли накосячить в сложном сетапе юнит-теста? Да, разумеется.
Разница только в том, что в первом случае косяк придется править только в одном месте, а во втором во всех тестах, использующих этот сетап.


По поводу того, что проверяется только вызов метода: это называется "тест на поведение". О том, что следует писать тесты на состояние, а не на поведение я упоминал в статье.


Ну и в целом, если юнит-тесты проходят, это еще далеко не значит, что у вас всё хорошо. Зато если они падают, значит всё точно плохо :)

Волшебная фея для юнит-тестов: DSL в C#

0
У нас в команде тоже нет консенсуса по этому вопросу) В статье оно приведено для ознакомления. Кому-то нравится, кому-то нет.

Волшебная фея для юнит-тестов: DSL в C#

0
  1. Это не так.
  2. То, что удобно использовать при разработке бизнес-логики не обязано быть удобным для тестов и DSL как раз помогает сгладить это несоответствие.
  3. Мы стараемся писать комментарии только в самых крайних случаях. А использовать BDD фреймворки в юнит-тестах мне представляется оверхедом посильнее DSL.
  4. Дебаг любого теста со сложным сетапом не самое приятное занятие. Согласен, DSL явно не поможет его упростить, но и не сильно усложнит.

Волшебная фея для юнит-тестов: DSL в C#

0

Я считаю, что самых лучших результатов можно добиться, если использовать AutoFixture вместе с кастомным DSL, а не вместо него, но это за скоупом статьи.

Волшебная фея для юнит-тестов: DSL в C#

0
Я думаю, тут нет однозначного ответа использовать или нет. Я считаю, что использование билдеров несёт больше плюсов чем минусов. Более того, с минусами сам ни разу не сталкивался. Возможно у вас другой опыт и это интересно.
Расскажите плз, как вам мешала необходимость изучения структуры билдеров?

Волшебная фея для юнит-тестов: DSL в C#

Волшебная фея для юнит-тестов: DSL в C#

Наш первый обед вместе: почему и как мы проводим тестовый день

0
Кроме парной работы, есть еще одна причина: мы постепенно переводим наше решение на .net core и переходим на маки. Студия, к сожалению, работать на маках пока не умеет(

Redux — пересмотр логики reducer'a и actions

0

Подход интересный, но константы всё-равно нужны. Экшены же как-то надо диспэтчить.

Про одного парня

0

Очень напоминает книгу "Проект феникс" про дев опс.


Статья хорошая. Как бывшему одинэснику было интересно узнать об упущенных возможностях)

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0
Да, что-то я погорячился. Вспомнил про примеры с наносекундами и решил, что оверхед не растет с ростом времени запроса.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0
Спасибо за советы. У нас сейчас как раз висит задачка на профилирование одно из сервисов. Попробуем сделать с PerfView.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0
Очень зависит от библиотеки. Например, коннектору к базе данных вполне стоит быть полностью асинхронным.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+2
10 милисекунд — это где-то на три-четыре порядка больше, чем время, уходящее на создание асинхронщины. В этом случае можно вообще не волноваться.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+1
Вообще вы, конечно правы в том, что async — это не панацея, и переводить решение на async просто потому что так сейчас модно, скорее всего не стоит. Однако, если ASP.NET решение упирается в пул потоков стоит наряду с увеличением пула рассмотреть вариант, при котором на hot path все вызовы будут полностью асинхронными.

Кроме того, набирают популярность managed решения, в которых у юзеров нет доступа к размеру пула потоков.

Я бы смотрел на async/await в ASP.NET так: микрософт предложил нам легкий способ работы с асинхронным кодом, который позволяет малой кровью подготовиться к хайлоаду «из коробки». По началу, он был кривой и косой, но уже в ASP.NET Core с ним стало вполне приятно работать и почти все известные проблемы убрали.

Кстати, поделитесь опытом: как вы с помощью PerfView пришли к выводу, что при использовании async/await сильный оверхед?

И еще вопрос:
Если же они работают медленно (>100мс) — на сервер никакой серьёзной нагрузки всё равно не создать

Можете пояснить: почему не создать?

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0

Справедливо. Поэтому Клэри и советует использовать ConfigureAwait (false) в библиотеках.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0

Всё правильно. Здесь отвязывается от контекста Task, который создается в StartWork, но Task, возвращаемый Task.Delay() всё еще привязан к контексту. Если перенести ConfigureAwait(false) в MyDelay, то дедлока не будет.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+1
Этот котик часть статьи) Картинка какбы говорит нам, что не нужно использовать Wait() без причины, иначе котику будет не хорошо)

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+1
ConfigureAwait(false) вообще отвязывает операцию от контекста синхронизации и отправляет ее в пул потоков. SynchronizationContext.Current становится равным null.
После ConfigureAwait(false) снимаются все ограничения наложенные контекстом ранее.

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0
Да, тут больше речь о методах, которые пробрасывают таски дальше.

Отдельное спасибо за ссылку на Клэри :) Этот пост я как-то пропустил(

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+4
Не просто лучше, а нужно выполнять синхронно. Но что если, например, нужно реализовать метод интерфейса, который возвращает Task?

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

+2
Да, статические анализаторы — хорошая штука. Но инструментами нужно пользоваться с умом, понимая, почему они считают код ошибочным.