FM
Если серьёзно, то мне действительно не ясно
Есть такой канал
Lil words make magic
Там очень крупные компании не боятся использовать в документации, сервисах достаточно обыватель кий язык
Size: a a a
2019 March 26
FM
НН
Fox Mulder
Есть такой канал
Lil words make magic
Там очень крупные компании не боятся использовать в документации, сервисах достаточно обыватель кий язык
Lil words make magic
Там очень крупные компании не боятся использовать в документации, сервисах достаточно обыватель кий язык
+ horoshii kanal
KM
хм, а у меня на проконтент вот так (если перехожу в регистрацию)
KM
в общем, непонятно - говорить начальству, покупать билеты в мск или нет)
FM
Надо не бояться писать нестандартно, понятно и красиво
FM
DB
Описание — "Возвращает все магазины в округе". Если я добавлю новое поле — оно автоматически появится в сваггере
А вот более интересная штука — как делать инвалидацию "ручной" документации при изменении кода. В питоне это довольно сложно из-за динамичности языка: https://t.me/piterpy_meetup/42372
NV
Привет!
ПФ
Всем привет! На одном из рпошлых мест работы мы делали ен так, но похоже.
1. Мы использовали spring restdocs
2. Документация формировалась в формате asciidoctor
3. Документация генерировалась тестами
4. Были проверки на покрытие тестами всего внешнего API
4.1 Что-то не покрыто? Падает билд
4.2 Не покрыто документирующими тестами? Падает билд
4.3 Поменялось API? Пишется ворнинг на билде
1. Мы использовали spring restdocs
2. Документация формировалась в формате asciidoctor
3. Документация генерировалась тестами
4. Были проверки на покрытие тестами всего внешнего API
4.1 Что-то не покрыто? Падает билд
4.2 Не покрыто документирующими тестами? Падает билд
4.3 Поменялось API? Пишется ворнинг на билде
ПФ
Кто-нибудь выгружает описания API в OpenAPI (swagger) из кода на Java? У вас есть тесты на полноту javadoc'ов? Поделитесь опытом в @docsascode, пожалуйста.
DB
А вот более интересная штука — как делать инвалидацию "ручной" документации при изменении кода. В питоне это довольно сложно из-за динамичности языка: https://t.me/piterpy_meetup/42372
но если упростить:
- построить граф вызовов
- если поменялось что-нибудь в этом графе — поднимаемся наверх до апи, инвалидируем документацию для этого эндпоинта
- построить граф вызовов
- если поменялось что-нибудь в этом графе — поднимаемся наверх до апи, инвалидируем документацию для этого эндпоинта
DB
интересно, кто-нибудь таким пользуется в продакшене 🤔
AP
Всем привет! На одном из рпошлых мест работы мы делали ен так, но похоже.
1. Мы использовали spring restdocs
2. Документация формировалась в формате asciidoctor
3. Документация генерировалась тестами
4. Были проверки на покрытие тестами всего внешнего API
4.1 Что-то не покрыто? Падает билд
4.2 Не покрыто документирующими тестами? Падает билд
4.3 Поменялось API? Пишется ворнинг на билде
1. Мы использовали spring restdocs
2. Документация формировалась в формате asciidoctor
3. Документация генерировалась тестами
4. Были проверки на покрытие тестами всего внешнего API
4.1 Что-то не покрыто? Падает билд
4.2 Не покрыто документирующими тестами? Падает билд
4.3 Поменялось API? Пишется ворнинг на билде
А можете про тесты рассказать подробнее?
ПФ
DB
Мы используем снепшоты: загружаем данные, проверяем что апи вернуло тоже, что и в прошлый раз.
DB
Если вернуло не то же, то такое изменение надо ручками осмысленно подтвердить
DB
Тоже самое используем на фронтенде, кстати:
chromaticqa.com
https://www.youtube.com/watch?v=p-LFh5Y89eM
chromaticqa.com
https://www.youtube.com/watch?v=p-LFh5Y89eM
НН
TIL что UI в батлфилде на тайпскрипте и реакте написан
DB
Фронтендер описывает "историю", в которой используется реальный компонент, пишет к ней документацию, специальная утилита делает снапшоты. Если внешний вид компонента поменялся, утилита шлёт варнинг и просит подтвердить изменение
Пример интерфейса для просмотра историй: https://storybooks-official.netlify.com/?path=/story/basics-button--all-buttons
Пример интерфейса для просмотра историй: https://storybooks-official.netlify.com/?path=/story/basics-button--all-buttons