Blazor server-side: тестирование

@kotelok · Регистрация: 08.08.2014

Author24 — интернет-сервис помощи студентам

Имеет ли смысл вообще писать тесты для blazor-страниц? И как это правильно делать?

* термин "контроллер" в тексте ниже употребляется не в привычном понимании класса, который принимает HTTP-запросы, а, скорее, пркак аналог ViewModel, на которую биндится View

Пока видится следующий сценарий:
1. Изначально есть 'Some.razor', который содержит разметку+код и на основании которого, при сборке проекта, автогенерируется окончательный класс страницы. Если оперировать привычными терминами, то этот razor-файл является View+ViewModel в одном флаконе (ну или View+Controller). Тестировать требуется Controller. И тут вопрос - нужно ли это вообще тестировать в отрыве от низлежащего слоя БЛ? Т.е. здесь вот, на уровне контроллеров, ведь даже логики валидации БЛ не будет, только немного преобразования данных из вводимого пользователем формата, в тот, что нужен на вход сервису, ну и проверки, что пользователь в принципе формат ввода соблёл. Ещё немного логики отображения/сокрытия элементов в зависимости от уровна авторизованности пользователя. Вся валидация предметной области и фактическая авторизация находятся уровнем ниже, в сервисах БЛ.

2. И если тестировать-таки это и делать грамотно, то получается, что придётся вынести всю логику из razor-файла в отдельный класс контроллера, который будет реализовывать интерфейс (описывающий внешний контракт контроллера) и в razor-файле инжектить контролер через этот интерфейс. Итого, на каждую страницу получается по три файла - 'ISomeController.cs', 'SomeController.cs', 'Some.razor'. Хотя, вроде бы, в интерфейсе здесь нет особой надобности, т.к. вряд ли будет потребность (и техническая возможность) как-то тестировать чисто слой View с моком контроллера.

3. При этом все низлежащие сервисы БЛ на этапе тестирования контроллера можно либо мокать, либо предоставлять в виде реальных зависимостей с настроенным полноценным тестовым окружением всех слоёв, вплоть до хранилища данных и реальной (физической) БД. И тут снова тот же вопрос - какой сценарий тестирования разумнее использовать? Т.е. реализовывать независимый набор тестов для каждого слоя приложения с замокиванием зависимостей низлежащих слоёв, или же писать только тесты уровня контроллеров и на вход тесту (через DI) давать полностью настроенное тестовое окружение с реальными сервисами, вплоть до хранилища данных? Это уже интеграционные тесты получаются, но зато самих тестов намного меньше. Мне более разумным видется замоканное тестирование отдельных слоёв, но вдруг я упускаю какие-то нюансы.

@yurickas · 06.07.2019, 11:47

Ну, по солиду разделять не только надо, но и необходимо. Только я выбрал не server-side, а host через сервер. В итоге, у меня 2 проекта, клиент и сервер. Клиент по идее должен исполняться на стороне клиента, но это немного не так. По документации всегда есть возможность исполнить компонент на стороне клиента или сервера.

И получается, имеем слой сервера (можно покрыть тестами), слой доступа к данным (можно покрыть тестами), и слой Service, для DI на стороне клиента (можно покрыть тестами) и слой представления Blazor (а вот что там тестировать - хез, разметку, верстку может. Весь код там должен контролировать визуальное состояние компонента вместо JS и его тоже какбы можно покрыть тестами, потому что компонент Blazor - это такой же класс C#, как и все остальные.)

@kotelok · 06.07.2019, 13:02 **[ТС]**

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

При этом тестировать ведь нужно и логику кода, и разметку, т.е. вот в этом компоненте из дефолтного шаблона, нужны следующие категории тестов:
1. Тест C#-кода, т.е. нужно проверить, что метод 'IncrementCount' реально делает то, что от него требуется, т.е. что после его вызова значение 'currentCount' изменяется на +1.
2. Тест разметки, т.е. что у кнопки 'Click me' корректно укзаны параметры привязки к коду и при её клике и в самом деле просходит вызов метода 'IncrementCount'. А так же, что корректно указана привязка к полю '@currentCount' в том месте, где это значение на страницу выводится.

Кликните здесь для просмотра всего текста

C#

@page "/counter"
 
<h1>Counter</h1>
 
<p>Current count: @currentCount</p>
 
<button class="btn btn-primary" @onclick="@IncrementCount">Click me</button>
 
@code {
    int currentCount = 0;
 
    void IncrementCount()
    {
        currentCount++;
    }
}

В принципе, на начальном этапе можно ограничиться только тестированием логики кода:
1. Вынести весь код в отдельный класс.
2. Унаследоваться от него в представлении.
3. В классе все свойства и методы сделать публичными, чтобы тесты имели к ним доступ.
4. Реализовать обычные юнит-тесты с замокиванием низлежащих сервисов.

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

@sau · 06.07.2019, 19:25

kotelok,

В инете статей про тестирование blazor-компонентов найти не удаётся.

нужно читать про методологии тестирования , в том числе интерфейсов , обычно это делается ручками ибо быстрее чем писать тест , если интерфейс шаблонный и переиспользуется во многих местах - можно написать автоматизацию действий пользователя. - как например это делается с браузерами через специальное апи. , а у MS есть даже UI Automation.

Ну и логику интерфейса можно так же вынести в сборку-классы и тестировать - тот же mvp шаблон , если конечно она не из двух строчек кода и тесты там действительно нужны.

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

Когда Вам нужно проверить работоспособность методов - быстрее и проще написать юнит/интеграционный тест чем собирать проект и пытаться выйти на этот метод в бизнес процессе , а когда Вам нужно протестировать функцию кнопки интерфейса - все же обычно быстрее ее нажать ручками , чем писать автотест - в общем по ситуации.

@kotelok · 06.07.2019, 21:13 **[ТС]**

sau
Единственная причина, по которой я вообще задумался о тестировании - защита уже существующего и отлаженного кода от внезапных багов. Т.е., на этапе начальной разработки и отладки функционала мне тесты ничем не помогут, т.к. на этом этапе я сам всё 10 раз прокликаю, пройдусь в отладке для контроля и напишу сценарии для тестировщиков. На этом этапе ошибки, просочившиеся в прод, большая редкость. Подавляющее же большинство прод-ошибок вонзникает либо при модификации старого/чужого кода, либо из-за каких-нибудь проблем в архитектуре, порождающих побочные эффекты, либо банально от невнимательности (например, случайно в дизайнере формы затёр привязку обрабочтика кнопки, которая к текущей задаче вообще отношения не имела, а потому в тестах упомянута не была и всплыла в проде в итоге).

@sau · 06.07.2019, 21:30

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

https://cs.petrsu.ru/~kulakov/... /08.ui.pdf
- тут в помощь различное ПО по автоматизации. , эта тема далекая от юнит.тестов и через них не решается.
- например , писать систему распознавания образов то еще занятие , проще тестировщика поднапрячь проверить и протыкать все кнопки перед релизом.

@kotelok 1287 / 866 / 258 Регистрация: 08.08.2014 Сообщений: 2,471
		1
	Blazor server-side: тестирование 05.07.2019, 14:52. Показов 3425. Ответов 5 Метки нет (Все метки) Имеет ли смысл вообще писать тесты для blazor-страниц? И как это правильно делать? * термин "контроллер" в тексте ниже употребляется не в привычном понимании класса, который принимает HTTP-запросы, а, скорее, пркак аналог ViewModel, на которую биндится View Пока видится следующий сценарий: 1. Изначально есть 'Some.razor', который содержит разметку+код и на основании которого, при сборке проекта, автогенерируется окончательный класс страницы. Если оперировать привычными терминами, то этот razor-файл является View+ViewModel в одном флаконе (ну или View+Controller). Тестировать требуется Controller. И тут вопрос - нужно ли это вообще тестировать в отрыве от низлежащего слоя БЛ? Т.е. здесь вот, на уровне контроллеров, ведь даже логики валидации БЛ не будет, только немного преобразования данных из вводимого пользователем формата, в тот, что нужен на вход сервису, ну и проверки, что пользователь в принципе формат ввода соблёл. Ещё немного логики отображения/сокрытия элементов в зависимости от уровна авторизованности пользователя. Вся валидация предметной области и фактическая авторизация находятся уровнем ниже, в сервисах БЛ. 2. И если тестировать-таки это и делать грамотно, то получается, что придётся вынести всю логику из razor-файла в отдельный класс контроллера, который будет реализовывать интерфейс (описывающий внешний контракт контроллера) и в razor-файле инжектить контролер через этот интерфейс. Итого, на каждую страницу получается по три файла - 'ISomeController.cs', 'SomeController.cs', 'Some.razor'. Хотя, вроде бы, в интерфейсе здесь нет особой надобности, т.к. вряд ли будет потребность (и техническая возможность) как-то тестировать чисто слой View с моком контроллера. 3. При этом все низлежащие сервисы БЛ на этапе тестирования контроллера можно либо мокать, либо предоставлять в виде реальных зависимостей с настроенным полноценным тестовым окружением всех слоёв, вплоть до хранилища данных и реальной (физической) БД. И тут снова тот же вопрос - какой сценарий тестирования разумнее использовать? Т.е. реализовывать независимый набор тестов для каждого слоя приложения с замокиванием зависимостей низлежащих слоёв, или же писать только тесты уровня контроллеров и на вход тесту (через DI) давать полностью настроенное тестовое окружение с реальными сервисами, вплоть до хранилища данных? Это уже интеграционные тесты получаются, но зато самих тестов намного меньше. Мне более разумным видется замоканное тестирование отдельных слоёв, но вдруг я упускаю какие-то нюансы. 0

@yurickas 163 / 138 / 35 Регистрация: 25.11.2015 Сообщений: 910
	06.07.2019, 11:47	2
	Ну, по солиду разделять не только надо, но и необходимо. Только я выбрал не server-side, а host через сервер. В итоге, у меня 2 проекта, клиент и сервер. Клиент по идее должен исполняться на стороне клиента, но это немного не так. По документации всегда есть возможность исполнить компонент на стороне клиента или сервера. И получается, имеем слой сервера (можно покрыть тестами), слой доступа к данным (можно покрыть тестами), и слой Service, для DI на стороне клиента (можно покрыть тестами) и слой представления Blazor (а вот что там тестировать - хез, разметку, верстку может. Весь код там должен контролировать визуальное состояние компонента вместо JS и его тоже какбы можно покрыть тестами, потому что компонент Blazor - это такой же класс C#, как и все остальные.) 1

@sau 2756 / 2059 / 384 Регистрация: 22.07.2011 Сообщений: 7,781
	06.07.2019, 19:25	4
	kotelok, В инете статей про тестирование blazor-компонентов найти не удаётся. нужно читать про методологии тестирования , в том числе интерфейсов , обычно это делается ручками ибо быстрее чем писать тест , если интерфейс шаблонный и переиспользуется во многих местах - можно написать автоматизацию действий пользователя. - как например это делается с браузерами через специальное апи. , а у MS есть даже UI Automation. Ну и логику интерфейса можно так же вынести в сборку-классы и тестировать - тот же mvp шаблон , если конечно она не из двух строчек кода и тесты там действительно нужны. Вообще , тесты нужно писать не ради тестов , а тогда , когда они реально помогают сократить трудозатраты и защитить от неочевидных ошибок. Когда Вам нужно проверить работоспособность методов - быстрее и проще написать юнит/интеграционный тест чем собирать проект и пытаться выйти на этот метод в бизнес процессе , а когда Вам нужно протестировать функцию кнопки интерфейса - все же обычно быстрее ее нажать ручками , чем писать автотест - в общем по ситуации. 1

@kotelok 1287 / 866 / 258 Регистрация: 08.08.2014 Сообщений: 2,471
	06.07.2019, 21:13 [ТС]	5
	sau Единственная причина, по которой я вообще задумался о тестировании - защита уже существующего и отлаженного кода от внезапных багов. Т.е., на этапе начальной разработки и отладки функционала мне тесты ничем не помогут, т.к. на этом этапе я сам всё 10 раз прокликаю, пройдусь в отладке для контроля и напишу сценарии для тестировщиков. На этом этапе ошибки, просочившиеся в прод, большая редкость. Подавляющее же большинство прод-ошибок вонзникает либо при модификации старого/чужого кода, либо из-за каких-нибудь проблем в архитектуре, порождающих побочные эффекты, либо банально от невнимательности (например, случайно в дизайнере формы затёр привязку обрабочтика кнопки, которая к текущей задаче вообще отношения не имела, а потому в тестах упомянута не была и всплыла в проде в итоге). 0

@sau 2756 / 2059 / 384 Регистрация: 22.07.2011 Сообщений: 7,781
	06.07.2019, 21:30	6
	kotelok, ну да , с этой целью и пишутся тесты , но функционал затертой привязки обработчика кнопки можно протестировать только вручную или через автоматизацию работы с интерфейсом , да и в целом , можно просто затереть случайно не только обработчик но и часть интерфейса ) , т.е тест должен убедится в наличии всех элементов , в том что все как нужно открывается/кликается/показывается или скрывается. https://cs.petrsu.ru/~kulakov/... /08.ui.pdf - тут в помощь различное ПО по автоматизации. , эта тема далекая от юнит.тестов и через них не решается. - например , писать систему распознавания образов то еще занятие , проще тестировщика поднапрячь проверить и протыкать все кнопки перед релизом. 1