Тестируем веб-API ASP.NET Core

[devopg]

у кого нету VS studio как это всё сделать?

[CrazyAlex25]

xunit не зависит от IDE. Можно в vscode или вообще в консоли запускать тесты. Вот руководство от microsoft по модульному тестированию Модульное тестирование C# в .NET Core с использованием dotnet test и xUnit

[euroUK]

ASP.NET Core — это новый веб-фреймворк, созданный корпорацией Майкрософт в качестве замещающей альтернативы устаревшей технологии, существующей со времен ASP.NET 1.0. Отказавшийся от устаревших зависимостей и разработанный с нуля, фреймворк ASP.NET Core 2.1 спроектирован для кросс-платформенного выполнения и дает разработчику гораздо большую производительность.

Как там в 2018, с новым .Net Core 2.1?

[beskaravaev]

Мне не нравятся статьи OTUS'а и всегда можно найти за что их поругать, но наверное не за «новый .Net Core 2.1» ибо есть плашечка «перевод» :)

[euroUK]

Да причем тут перевод вообще?

Я против тупого копипаста с нулевым пониманием темы. Если посмотреть пользователя, то он в день по десяток статей заливает. Абсолютно бесполезных.

Я не знаю, о чем думают пиарщики, как по мне, такие действия не только не рекламирует компанию, а скорее лишь подчеркивают полный непрофессионализм. Чему там могут научить такие кадры — я лично ХЗ.

Сама статья от 2018 года. С тех пор вышли 2.2, 3.0, 3.1 и 5. И если в оригинале допустимо говорить о «новинке» которой к слову тоже уже пару лет было, то еще через 2 года и 4 новых версии — странно.

Более того, в чем вообще польза данной статьи — непонятно. Проверять, получаем мы статус ОК от HTTP запроса? Да он может отваливаться просто потому, что порт занят другим процессом. Как это свидетельствует о качестве кода? Зачем вообще нужны такие тесты?

В другой статье этого автора www.infoq.com/articles/advanced-architecture-aspnet-core чувак на полных щах пишет

public interface IAlbumRepository : IDisposable
{
	Task<List<Album>> GetAllAsync(CancellationToken ct = default(CancellationToken));
Task<Album> GetByIdAsync(int id, CancellationToken ct = default(CancellationToken));
       Task<List<Album>> GetByArtistIdAsync(int id, CancellationToken ct = default(CancellationToken));
       Task<Album> AddAsync(Album newAlbum, CancellationToken ct = default(CancellationToken));
       Task<bool> UpdateAsync(Album album, CancellationToken ct = default(CancellationToken));
       Task<bool> DeleteAsync(int id, CancellationToken ct = default(CancellationToken));
}

демонстрируя «уровень». И это университетский преподаватель. Вот таких статей явно не надо, и пользы в них нет, только вред.

Так что все просто — не понимаешь о чем статья — не переводи и не рекомендуй.

[leotsarev]

Расскажите, что тут не так с вашей точки зрения. А то много идей

[euroUK]

Прежде всего, сам репозиторий это грубая ошибка.
DbSet это уже репозиторий. И он уже предоставляет все те методы, которые тут используются. Нет никакой необходимости оборачивать его еще в один уровень.

Более того, нет никакой необходимости писать интерфейс для конкретного типа, который явно не предполагает несколько реализаций. Это еще одно усложнение логики. Если уж делать, то это должен быть интерфейс типа

 IRepository<T>

.

Более того, контекст используется как Disposable, при этом контекст в стартапе используется в рамках пула. И даже я не знаю, хорошо ли диспозить контекст, если он получен в рамках пула.

[leotsarev]

1. Я поддерживаю в принципе ваш подход мол DbSet это репозиторий. Но практика показывает, что ВООБЩЕ говоря этот подход далеко не единственный, и (а) есть много людей, который предпочитают делать абстрации над EF и (б) есть например подход clean archirecture, который предусматривает, что бизнес-логика не может зависеть от репозитория (а репозиторий должен уметь загружать и сохранять доменные объекты).

   
   

2. Опять же про интерфейс. Во-первых, есть подход clean architecture (например в домене объявляются интерфейсы, а в зависимых проектах DAL реализуются). Во-вторых, моки, тестирование etc

   
   

3. Про IRepository<T>. Его-то как раз кмк нет смысла объявлять (потому что это полный аналог DbSet), а вот в IAlbumRepository могут начать появляться методы вроде LoadAlbumsByAuthor и тогда его использование станет более оправдано.

   
   

4. Disposable И тут скорее согласен. При DI подходе не дело управлять временем жизни объекта вручную, САМ контекст при этом может быть вполне IDisposable, но ни к чему этому знанию протекать в интерфейс.

   
   

Итого я скорее с вами согласен, но не согласен в том, что это прям ужас-ужас. Многие так пишут, и могут быть причины так писать в рамках многих подходов.

[euroUK]

1) Вот и я об том же говорю. Благодаря таким «экспертам» которые пишут книжки по «чистой архитектуре» не имея релевантного опыта в текущем стэке и рождаются франкенштейны. Раньше была необходимость писать репозитории, которые абстагировали логику доступа к данным для того, чтобы можно было менять провайдера БД. Но EF Core это уже такая абстракция, к нему уже есть провайдеры к БД и нет никакой необходимости городить свой огород сверху.

Что касается бизнес-логики и ее зависимости. Я не говорю, что она должна зависеть. Однако репозиторий, особенно такой как в статье, не решает никаких проблем. Я предпочитаю выносить логику работы в Data Access Layer, в который инжектится DbContext, и уж он-то и реализует специфичные операции с данными. Понятно, что под репозиторием мы можем понимать и DAL, но по факту, это разные вещи. Репозиторий скорее относится к домену и по идее, не должен иметь методы для авторов и альбомов вместе. В то де время DAL делается с упором на инкапсуляции бизнес-логики и нет никаких проблем возвращать разные модели в рамках одного сервиса, если это продиктовано требованиями.

2) Я понимаю, для чего в принципе существуют интерфейсы. Однако, опять же, нужно понимать зачем их использовать. Я видел сотни проектов, где была куча интерфейсов, которые практически никак не использовались. Просто раздувается кодовая база без какого-либо смысла. И да, кстати, вопрос мока контекста с нужными данными — это вообще боль в случае, когда это чуть больше, чем круд. Проще инжектить реальную тестовую базу.

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

А люди почитав таких авторов, начинают обмазывать круд юнит тестами, где проверяют статус 200, вместо того, чтобы проверять действительно важные вещи.

[semmaxim]

1. IDbSet иногда слишком избыточен (например, когда в принципе нельзя менять данные в БД — только читать, да и методов в нём просто слишком много), иногда слишком ограничен (когда нужно сделать более сложную выборку или выполнить прямо текстовый sql-запрос и скрыть это от внешних классов). Иногда требуется отвязаться от собственно EF (например, рассчитывая использовать Dapper или NHibernate впоследствии).
2. Писать интерфейс для конкретной реализации — это стандартная и распространённая практика. Наоборот, многие вообще считают хорошим тоном, что в DI/IoC-контейнере регистрируются ТОЛЬКО интерфейсы сервисов. К тому же в автоматических тестах использовать интерфейсы гораздо проще, чем классы с абстрактными/виртуальными методами.
3. Странно это делать, конечно, но почему бы и не делать Dispose?

[MaxRokatansky]

«Пользователь публикующий десяток бесполезных (действительно ли таких бесполезных?) статей в день» — это корпоративный аккаунт компании. И да, статьи заливает в блог редактор, но подбираются и переводятся статьи экспертами, которые разбираются каждый в своей области. Статья действительно не самая новая, но как пример вполне имеет право на существование, а если Вам есть чем дополнить и в чем поправить автора — это же прекрасно. Как раз в таком обсуждении зачастую рождается истина и толковые идеи.