dyuvzhenko
commented
7 years ago @dhilt Да, тесты правда слишком избыточны. Не стоило наверное писать тесты на статическую часть верстки, то есть проверять абсолютно каждый html-тег и его параметры. Css-стили стили могут меняться, теги могут меняться - и если это будет происходить, придется попросту дублировать код. А ошибок с просто статическим рендером быть не должно. А вот та часть рендера компонента, которая зависит от роли пользователя, pending'а, i18n и прочих условий - вот только эти места и стоило покрыть тестами. Ну и методы на компоненте, их тестирование возможно стоило все же написать с помощью библиотеки sinon, как это описано в библиотеке enzyme. В общем да, я думаю можно смело большую часть кода с тестированием компонентов убирать.
Метод doAuthorize вынес.
Бранчи crud-methods и test-frontend чуточку параллельно развивались (но сольются без проблем). В crud-methods есть что-то, чего нет в test-frontend, также и с test-frontend. Я к тому, что может удачным порядок сливания бранчей будет следующим: сначала crud-methods в test-frontend, далее test-frontend в master. Как-то так.
Следующей задачей тогда буду думать насчет новой БД-сущности и тем, как связать будущие pages и users.
А тесты я бы хотел кардинально видоизменить, полностью убрать всю статику как минимум. Может стоит открыть в некотором смысле экспериментальный бранч test-frontend-2?
dhilt
Мы вплотную подошли к релизу, проделана большая работа, я до сих пор не успеваю посмотреть все по порядку. Мне кажется, у нас избыточные тесты для клиента, но пока не будем пытаться их упрощать, подождем соответствующего случая. Например, нам понадобится дописать компонент и мы сразу увидим, что мешает, а что полезно.
По API layer скажу сразу, что это была моя фантазия, не подкрепленная никаким опытомЮ но мне нравится итог. Только одно глобальное но у меня есть на этот счет, а именно doAuthorize. Это явно не контроллерный метод, но и не метод одного конкретного API. Это API helper. Давай вынесем этот метод в отдельный модуль ./prod/api/_helper.js или хотя бы ./prod/api/doAuthorize.js. И будет хорошо.
В ближайшее время я солью весь оставшийся код в мастер. После я выдам людям один переводческий логин-пароль и начнется новая эра.
На счет дальнейшего движения, я вижу создание нового типа БД сущностей, а имнно статей/страниц (новый тип pages). Туда должны будут переместиться описания Переводчиков, а также страница О проекте. Описание переводчиков должно быть выдрано из типа users и перермещено в pages. О том, как организовать связь между сущностями, предстоит подумать, изучить принятые для эластика подходы, заложить расширение на будущее...
Также необходимо дописать механизм миграций. Накат миграций (не db-reset, а новый db-migrate) должен учитывать прежние запуски и прогонять только новые миграции, сразу же отмечая их как выполненные, чтобы исключить повторный прогон при следующем db-migrate.
К этому неплохо бы дописать механизм отката миграций, но в ближайшее время мы точно не будем этим заниматься. Еще я уверен, что все это уже написано и можно поискать готовые решения. Просто наши текущие миграции очень тяжелые, и 90% кода уникальны относительно общих инфраструктурных миграционных задач.
Хотел тебя попросить посмотреть на https://github.com/angular-ui/ui-scroll. Я хочу перенести сборку с Grunt на Webpack, но никак не могу заставить себя заняться этим. Не так давно я перенес на Webpack компиляцию дистрибутива и это был значительный кусок задачи по отказу от Grunt, но нужно еще перенестии все остальное, все Grunt-задачи, фигурирующие в package.json в разделе scripts. Было ли бы тебе интересно взглянуть на это?