Здравствуйте, Pauel, Вы писали:

P>>>Когда имплементишь апи, то эту часть и так нужно покрыть тестами, что естественно.
P>·>Вообще элементарно. Результат кодогенерации очень надёжно тестируется компилятором.
P>Детский сад. Как компилятор поможет, если генератор "забыл" кое какие методы сгенерировать? Компилится, значит круто?
P>Вообще то нет — нужны тесты.
Это всё донельзя элементарно. Например, если тебе нужно сгенерировать interface MyApi {void m1(); void m2();} Кладёшь рядом файлик class ExpectedApiImpl implements MyApi{@Override m1(); @Override m2();} и получаешь ошибки компиляции если генератор что-то "забудет".
В некоторых случаях бывает и полный end-to-end тест — генератор генерит готовый демо-проект с системой билда и тестами. Так что проверить результат генерации — сбилдить свежесгенерённый проект с прогоном всех тестов.

P>·>А что гарантирует решение всех проблем?
P>Тесты на целевой системе, то есть, проде.
Тесты гарантируют решение всех проблем. Я так и знал. Спасибо. Вопросов больше нет.

P>·>тестовым юзером.
P>Если на проде не тестируешь, то всегда огромный шанс, что багу первым найдет юзер, напорется, по разными причинам, например — никогда не бывает 100% соответствия стейджинга и прода.
Ну не делайте так.

P>>>Я ж сказал — исключить кодогенерацию, оставить генерацию схемы для внешних консумеров, если у них платформа отличная от твоей.
P>·>Ты расскажи. Зачем схема внешним консьюмерам?
P>Они это апи покупают, делают вызовы.
Зачем им именно _схема_? Сгенерите им javadoc|аналог по вашему коду и вперде.

P>>>Если такая же — ты им даешь клиент который у тебя готов на этапе создания апи. Напоминаю — описание апи дает нам автоматически и сам клиент.
P>·>Не распарсил. Что автоматически?
P>Очень просто — описываешь интерфейс, обычный, либа сама делает из него клиент. Для внутреннего использования кодогенерация исключается.
Это пожалуйста. Правда типично это закончится тем, что интерфейс для внутреннего использования будет немного другим, чем то что можно отдавать наружу и будете стараться усидеть на двух стульях.

P>Не под силу, в том то и дело. Хороший кодогенератор это большие трудозатраты. У меня в мейнтенансе два таких.
Это не сложнее схемогенератора. И явно проще, чем схемогенератор+кодогенератор.

P>>>·>Хорошо, уже теплее. Ради чего стараться-то? Что внешние консьюмеры будут с этим твоим экспортированным АПИ делать будут?
P>>>Что им надо делать, то и будут.
P>·>Ясно. Проблемы консьюмеров шерифа не волнуют. ЧТД.
P>Ты бы лучше мысли формулировал. Консумеры покупают апи, вызывают, оплачивают вызовы и тд.
Что они будут делать со схемой, которая даже с трудом парсится?

P>>>Схемогенератор это вещь намного проще. Типичный разработчик искаропки умеет генерировать json по набору данных, все приложения состоят из такой логики. А вот внятную кодогенерацию сделать — это вещь нетривиальная.
P>·>Гораздо проще. Валидировать сгенерённый код можно компилятором. Валидировать генерённый json и по каким критериям — не знаю как.
P>Детский сад — как компилер проверит, что есть два метода, которых быть не должно ?
Мы же ифейс генерим? Будет ошибка, что методы не имплементированы.

P> Или что нет двух методов, которые быть должны. Код то компилится!
Можно даже банально набрать код в IDE, который хочешь чтобы сгенерировался, коммитишь как образец и пишешь тест посимвольного сравнения.

P>·>Нет. Пытаюсь достучаться. Ты должен писать такие метаданные и такой интерфейс, который хорошо ложится в openapi. Иначе то что нагенерится будет коту под хвост.
P>Для этого есть тесты апи, которые работают через openapi тул, безо всякой кодогенерации специального клиента.
Для этого есть тесты апи, которые работают не через openapi тул.

P>>>Мне нужна генерация схемы + тесты по этой схеме. Тестировать конкретным генереным клиентом в корне неверно.
P>·>Ты так и не рассказал зачем нужная эта схема.
P>По моему ты сейчас юродствуешь. Схема нужна внешним консумерам, что бы они могли вызывать твой сервис.
Что значит "нужна"? Как именно они её будут использовать? Чтобы вызывать твой сервис можно использовать банальный curl.

P>>>·>Сделать два кодогенератора проще, чем схемогенератор+кодогенератор.
P>>>Нужен только схемогенератор — апи будет тестироваться не абы чем, а конкретным тулом который умеет openapi.
P>·>Зачем? Чтобы что?
P>Что бы убедиться, что апи работает согласно требованиям.
Требования _задаются_ в FRD. Сгенерённая по коду схема может лишь показать, что works as coded, про требования оно ничего сказать не может в принципе. Ах да, я забыл, у вас же тесты гарантируют решение всех проблем.

P>>>Ты не знаешь ни версию кодогенератора у клиента, ни платформу, ни даже язык программирования.
P>·>Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.
P>Попробовали, получили отстой. Дальше что?
Т.е. вы поняли что у клиентов тоже будет получаться отстой. И норм. Гы.

P>>>Ну так дай ссылку дай на сообщение, где НС это утверждает. Насколько я понимаю, ты искусно вырезал часть его утверждения.
P>·>Вот

Автор: varenikAA
Дата: 07.09.20

полная цитата:
P>·>

Чисто теоретически я знаю как все таки сделать нормальный генератор, но это большая работа, включающая допиливание swashbuckle на предмет добавления в swagger.json дополнительной метаинформации о семантике методов.

P>·>Т.е. чтобы сгенерённую спеку можно было использовать клиентам, требуется дополнительная метаинформация и допиливание схемогенератора. И это всё теоретически.
P>То есть, он утверждает, что трудно сделать хороший кодогенератор, т.к. отсутствует метадата по семантике
Она отсутсвует потому что swashbuckle её не умеет добавлять.

P>Как ты этот вопрос обойдешь ручным набиванием схемы?
Просто впишешь семантическую метадату в схему.

P>>>И чем тебе пулл реквест поможет если лицуха GPL ? Такой софт не факт что можно в любой конторе использовать.
P>·>Имя софта в студию. Или ты теоретег?
P>Да полно таких и не только проблем. Мы делали про openapi большой ресёрч, сравнивали состояние дел в разных кодогенераторах.
И? Имя-то будет?

P>>>Это твои домыслы. У него ничего не сказано, либу он берет, или врукопашную чегото делает.
P>·>Его цитаты: "пришли к выводу что писать клиентов нужно руками". "добавления в swagger.json дополнительной метаинформации".
P>Именно. Раз кодогенератор не умеет в семантику, а он не умеет, т.к. в манифесте такой фичи нет, то остаётся один вариант — писать руками.
Почему в манифесте нет-то? Потому что swashbuckle недопилен.

P>>> Нам нужно не просто абы что абы куда послать, а дать гарантии, что тест посланый согласно спецификации OpenAPI будет понят твоим сервисом.
P>·>Зачем? Если эту спецификацию ни для чего более использовать не выходит?
P>Эта спека нужна для того, что бы люди могли твой сервис использовать.
Конкретно рассказывай. Нужна для чего? Чтобы просто сервис использовать можно сделать тупо curl.

P>Не в курсе, может взяли смержили кусочки рукописных файлов, да слегка обработали
Сам-то веришь?

Здравствуйте, ·, Вы писали:

P>>Вообще то нет — нужны тесты.
·>Это всё донельзя элементарно. Например, если тебе нужно сгенерировать interface MyApi {void m1(); void m2();} Кладёшь рядом файлик class ExpectedApiImpl implements MyApi{@Override m1(); @Override m2();} и получаешь ошибки компиляции если генератор что-то "забудет".

Детский лепет. Кто будет этот класс генерить? Тот же генератор или еще один генератор? То есть, как понять, может тут должен быть метод m0 или m3
Или, наоборот, одно из 1 или 2 быть не должно.

P>>Тесты на целевой системе, то есть, проде.
·>Тесты гарантируют решение всех проблем. Я так и знал. Спасибо. Вопросов больше нет.

Я слегка преувеличил, но сути это не меняет — система в эксплуатации точно так же нуждается в тестировании, мониторинге, итд.
Например, чем выше цена ошибки, тем чаще надо тестировать именно прод.

P>>Если на проде не тестируешь, то всегда огромный шанс, что багу первым найдет юзер, напорется, по разными причинам, например — никогда не бывает 100% соответствия стейджинга и прода.
·>Ну не делайте так.

Смешно. Это принципиально невозможно — на проде другой стейт, другой нетворк, другие зависимости, другая нагрузка.

P>>Они это апи покупают, делают вызовы.
·>Зачем им именно _схема_? Сгенерите им javadoc|аналог по вашему коду и вперде.

Они сами просят.

P>>Очень просто — описываешь интерфейс, обычный, либа сама делает из него клиент. Для внутреннего использования кодогенерация исключается.
·>Это пожалуйста. Правда типично это закончится тем, что интерфейс для внутреннего использования будет немного другим, чем то что можно отдавать наружу и будете стараться усидеть на двух стульях.

Напишешь другой — будет другой. А если он один, то он всего один. Он не может быть "немного другим"

P>>Не под силу, в том то и дело. Хороший кодогенератор это большие трудозатраты. У меня в мейнтенансе два таких.
·>Это не сложнее схемогенератора. И явно проще, чем схемогенератор+кодогенератор.

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

    @Api('v2/api')
    @Use(Correlation, Hooks)
    class Api {
       @Get()
       @ResponseHeaders()
       method(@IsValid(idSchema) @Query('id') id:string, @RequestId() requestId?:string):Result<Entity>;
    }
...
test('should expose metadata', () => {

    expect(metadataFrom(Api)).to.deep.eq({ ... });
    expect(openapiFrom(Api)).to.deep.eq({ ... });
});

P>>Ты бы лучше мысли формулировал. Консумеры покупают апи, вызывают, оплачивают вызовы и тд.
·>Что они будут делать со схемой, которая даже с трудом парсится?

Наша нормально парсится.

P>>Детский сад — как компилер проверит, что есть два метода, которых быть не должно ?
·>Мы же ифейс генерим? Будет ошибка, что методы не имплементированы.

Я не могу понять твои идеи. Почему только интерфейс? Нужен весь клиентский код.

P>> Или что нет двух методов, которые быть должны. Код то компилится!
·>Можно даже банально набрать код в IDE, который хочешь чтобы сгенерировался, коммитишь как образец и пишешь тест посимвольного сравнения.

Ну то есть, ты собрался и генерить код, и тут же его руками накидать, что бы он в юнит тестах был. Мощно! Как это я не догадался.

P>>Для этого есть тесты апи, которые работают через openapi тул, безо всякой кодогенерации специального клиента.
·>Для этого есть тесты апи, которые работают не через openapi тул.

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

P>>По моему ты сейчас юродствуешь. Схема нужна внешним консумерам, что бы они могли вызывать твой сервис.
·>Что значит "нужна"? Как именно они её будут использовать? Чтобы вызывать твой сервис можно использовать банальный curl.

Как именно
1. есть тулы для работы с опен апи, для тестов
2. они могут использовать какой угодно генератор, мы не делаем предположений. Вдруг у них перл — это их зона ответственности.
3. могут и руками наструячить

P>>Что бы убедиться, что апи работает согласно требованиям.
·> Требования _задаются_ в FRD.

От апи есть вполне конкретные ожидания. Это часть требований.

> Сгенерённая по коду схема может лишь показать, что works as coded

Это всё равно наши ожидания. И нужно тестировать апи в явном виде.

P>>·>Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.
P>>Попробовали, получили отстой. Дальше что?
·>Т.е. вы поняли что у клиентов тоже будет получаться отстой. И норм. Гы.

Именно, если они возьмут генераторы и подкинут им рукописный манифест, то будет отстой. Элментарно — каждый генератор поддерживает некоторое подмножество фич опенАпи.
А раз так, то нужен внятный контроль, автоматический, что может быть, а чего не может быть в апи.
Соответственно, мы берем либу определенную которая выдает простой манифест, который можно скормить почти любому генератору.

P>>То есть, он утверждает, что трудно сделать хороший кодогенератор, т.к. отсутствует метадата по семантике
·>Она отсутсвует потому что swashbuckle её не умеет добавлять.

Это уже дело десятое. Главное, что хорошего кодогенератора нет.

P>>Как ты этот вопрос обойдешь ручным набиванием схемы?
·>Просто впишешь семантическую метадату в схему.

Ну да, и выяснишь, что кодогенератор такое не умеет. Гы гы

P>>Да полно таких и не только проблем. Мы делали про openapi большой ресёрч, сравнивали состояние дел в разных кодогенераторах.
·>И? Имя-то будет?

Зачем? Ты хочешь что бы я повторил тот ресерч ? Их тучи, у меня нет желания перебирать десятки либ.

P>>Эта спека нужна для того, что бы люди могли твой сервис использовать.
·>Конкретно рассказывай. Нужна для чего? Чтобы просто сервис использовать можно сделать тупо curl.

Уже много раз рассказал. Не понимаю твои вопросы.

P>>Не в курсе, может взяли смержили кусочки рукописных файлов, да слегка обработали
·>Сам-то веришь?

Факт в том, что мы не знаем происхождение того файла. Там точно не с апи проблема.

Здравствуйте, Pauel, Вы писали:

P>·>Это всё донельзя элементарно. Например, если тебе нужно сгенерировать interface MyApi {void m1(); void m2();} Кладёшь рядом файлик class ExpectedApiImpl implements MyApi{@Override m1(); @Override m2();} и получаешь ошибки компиляции если генератор что-то "забудет".
P>Детский лепет. Кто будет этот класс генерить? Тот же генератор или еще один генератор? То есть, как понять, может тут должен быть метод m0 или m3
P>Или, наоборот, одно из 1 или 2 быть не должно.
Зачем его генерить? Цель теста проверить, что генератор генерит то, что мы ожидаем он должен генерить. Пишем образец и ассертим что результат совпадает с образцом.
Почему-то написать образцовый кусок схемы ты проверить в состоянии на валидность и корректность (как кстати?), а кусок кода на шарпе (который элементарно проверить не только компилятором, но даже тесты написать!) — прям затык в мозгу, и ничего не понимаешь.

P>>>Они это апи покупают, делают вызовы.
P>·>Зачем им именно _схема_? Сгенерите им javadoc|аналог по вашему коду и вперде.
P>Они сами просят.
Зачем они просят-то?

P>>>Не под силу, в том то и дело. Хороший кодогенератор это большие трудозатраты. У меня в мейнтенансе два таких.
P>·>Это не сложнее схемогенератора. И явно проще, чем схемогенератор+кодогенератор.
P>Ровно наоборот — у меня есть с чем сравнивать. Кодогенератор писать сложнее, тяжело мейнтейнить, и его крайне тяжело тестировать.
P>А вот обложить тестами генератор схемы — это вообще дело плёвое, чисто юнит тесты
Да тоже самое. Просто инвертируешь.

P>

P>    @Api('v2/api')
P>    @Use(Correlation, Hooks)
P>    class Api {
P>       @Get()
P>       @ResponseHeaders()
P>       method(@IsValid(idSchema) @Query('id') id:string, @RequestId() requestId?:string):Result<Entity>;
P>    }

Вот это и положи в expected output теста.
А тест будет просто наоборот:

P>...
P>test('should generate interface', () => {

P>    expect(generate({"v2/api": {"get": {"operationId": "method", "parameters":{ ["name": "id", "in": "query"]...}}})).to.eq(file("exppected/Api.cs"));
P>});
P>

P>>>Ты бы лучше мысли формулировал. Консумеры покупают апи, вызывают, оплачивают вызовы и тд.
P>·>Что они будут делать со схемой, которая даже с трудом парсится?
P>Наша нормально парсится.
Что они будут делать со схемой?

P>>>Детский сад — как компилер проверит, что есть два метода, которых быть не должно ?
P>·>Мы же ифейс генерим? Будет ошибка, что методы не имплементированы.
P>Я не могу понять твои идеи. Почему только интерфейс? Нужен весь клиентский код.
Аналог твоего "class Api" с навешанными аннотациями. Только интерфейс вместо класса. Или какой ещё клиентский код ты имеешь в виду? В любом случае — код это просто код, который можно скомпилять и даже выполнить и заасертить резултат.

P>>> Или что нет двух методов, которые быть должны. Код то компилится!
P>·>Можно даже банально набрать код в IDE, который хочешь чтобы сгенерировался, коммитишь как образец и пишешь тест посимвольного сравнения.
P>Ну то есть, ты собрался и генерить код, и тут же его руками накидать, что бы он в юнит тестах был. Мощно! Как это я не догадался.
Руками накидать образец для теста же. Другие догадались давным давно.

P>>>Для этого есть тесты апи, которые работают через openapi тул, безо всякой кодогенерации специального клиента.
P>·>Для этого есть тесты апи, которые работают не через openapi тул.
P>Ну тогда нет гарантии, что внешние консумеры вообще чтото вызвать смогут. Они то будут исползовать опен апи, а ты протестировал абы как.
P>Итого — а хрен его знает, чего ждать у них.
Как они будут использовать опенапи? Вот пишут они клиента на... ээ.. допустим go. Куда они впихнут спеку, чтобы её использовать?

P>>>По моему ты сейчас юродствуешь. Схема нужна внешним консумерам, что бы они могли вызывать твой сервис.
P>·>Что значит "нужна"? Как именно они её будут использовать? Чтобы вызывать твой сервис можно использовать банальный curl.
P>Как именно
P>1. есть тулы для работы с опен апи, для тестов
Ну это не для них, а для вас. Демка, чтобы сейлзы могли впаривать ваш эээ... продукт. В свой код они не смогут встроить, т.к.:

P>2. они могут использовать какой угодно генератор, мы не делаем предположений. Вдруг у них перл — это их зона ответственности.
Ты сам заявил, что не смогут: "опробовали, получили отстой.". Ночной Смотрящий тоже говорил, что пробовал с тем же результатом.
А вот если бы вы сами использовали кодогенератор, это было бы вашей заботой и отстоя было бы хоть чуточку меньше, eat your own dog food.

P>3. могут и руками наструячить
Угу. О чём я и говорю.

P>>>Что бы убедиться, что апи работает согласно требованиям.
P>·> Требования _задаются_ в FRD.
P>От апи есть вполне конкретные ожидания. Это часть требований.
Так это ничего не докажет. Вы из кода генерите тесты самого кода. Порочный круг.

P>>>·>Не важно. Можно взять несколько самых популярных, попробовать самому и оформить в виде туториала для новых клиентов.
P>>>Попробовали, получили отстой. Дальше что?
P>·>Т.е. вы поняли что у клиентов тоже будет получаться отстой. И норм. Гы.
P>Именно, если они возьмут генераторы и подкинут им рукописный манифест, то будет отстой. Элментарно — каждый генератор поддерживает некоторое подмножество фич опенАпи.
P>А раз так, то нужен внятный контроль, автоматический, что может быть, а чего не может быть в апи.
P>Соответственно, мы берем либу определенную которая выдает простой манифест, который можно скормить почти любому генератору.
Задумка хорошая, но не работает.

P>>>То есть, он утверждает, что трудно сделать хороший кодогенератор, т.к. отсутствует метадата по семантике
P>·>Она отсутсвует потому что swashbuckle её не умеет добавлять.
P>Это уже дело десятое. Главное, что хорошего кодогенератора нет.
Куда дели-то? Вот взял я swagger-codegen-cli.jar и сгенерил для https://github.com/googlemaps/openapi-specification всё завелось, и клиента и сервера под спринг и под котлин. Теперь могу спокойно вписывать логику в клиента и наваять местный стаб-сервер для тестов.

P>>>Как ты этот вопрос обойдешь ручным набиванием схемы?
P>·>Просто впишешь семантическую метадату в схему.
P>Ну да, и выяснишь, что кодогенератор такое не умеет. Гы гы
Кодогенератор умеет не больше, чем есть в спеке. И не меньше.

P>>>Да полно таких и не только проблем. Мы делали про openapi большой ресёрч, сравнивали состояние дел в разных кодогенераторах.
P>·>И? Имя-то будет?
P>Зачем? Ты хочешь что бы я повторил тот ресерч ? Их тучи, у меня нет желания перебирать десятки либ.
И все они gpl и не позволяют шаблоны подправлять? Врёшь.

P>>>Эта спека нужна для того, что бы люди могли твой сервис использовать.
P>·>Конкретно рассказывай. Нужна для чего? Чтобы просто сервис использовать можно сделать тупо curl.
P> Уже много раз рассказал. Не понимаю твои вопросы.
Не рассказывал, а отмазывался "просят".

P>>>Не в курсе, может взяли смержили кусочки рукописных файлов, да слегка обработали
P>·>Сам-то веришь?
P>Факт в том, что мы не знаем происхождение того файла. Там точно не с апи проблема.
Да что там гадать-то? Очевидно же https://stackoverflow.com/questions/66909557/swashbuckle-is-generating-an-invalid-json-with-system-collections-generic-keyval Схемагенератор же просто и удобно... В апи понаписали генерики, которые swashbuckle переварить не смог и вывалил какашку.

Здравствуйте, ·, Вы писали:

·>Зачем его генерить? Цель теста проверить, что генератор генерит то, что мы ожидаем он должен генерить. Пишем образец и ассертим что результат совпадает с образцом.

Написал, покрыл тестами. Баги могут быть, или у тебя и здесь багов не бывает?
А раз баги бывают, то как ты будешь детектить, что вдруг сгенерилось не то? Упс!
А со схемой можно это вопрос решить разными способами.

P>>Они сами просят.
·>Зачем они просят-то?

Используют для генерации, для тестов, итд.

P>>

P>>    @Api('v2/api')
P>>    @Use(Correlation, Hooks)
P>>    class Api {
P>>       @Get()
P>>       @ResponseHeaders()
P>>       method(@IsValid(idSchema) @Query('id') id:string, @RequestId() requestId?:string):Result<Entity>;
P>>    }
·>

·>Вот это и положи в expected output теста.

Так себе идея. Кодогенератору надо дать выхлоп в виде пакета, модуля или даже целого солюшна, с депенденсами, помкой и прочими приседаниями. Соответственно, сравнивать не кусочек текста, а дерево файлов. И это уже не хухры мухры — долго и муторно.

·>А тест будет просто наоборот:

Крайне хрупкий тест, т.к. если ты вдруг поменял мелочь, у тебя все тесты вдруг упали, и надо обновлять не фрагменты кода, а вообще всё.
Например — твой генеренный код использует кое какие депенденсы. Упс — часть из них протухла. Гы-гы, меняй шаблоны. Фиксай все файлы заготовок для тестов.
В этом плане схема вещь достаточно стабильная, меняется куда реже, чем генератор кода и шаблоны к нему.

P>>Наша нормально парсится.
·>Что они будут делать со схемой?

Подкидывают своим тулам, для тестов или генерации клиентов под свои платформы.

P>>>>Детский сад — как компилер проверит, что есть два метода, которых быть не должно ?
P>>·>Мы же ифейс генерим? Будет ошибка, что методы не имплементированы.
P>>Я не могу понять твои идеи. Почему только интерфейс? Нужен весь клиентский код.
·>Аналог твоего "class Api" с навешанными аннотациями. Только интерфейс вместо класса.

Алё — ты читаешь вообще? — этот класс и есть полнофункциональный клиент, и он же есть описание АПИ.
Вот так вызывается

const new api = new API();

return api.method('an id');

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

P>>Ну то есть, ты собрался и генерить код, и тут же его руками накидать, что бы он в юнит тестах был. Мощно! Как это я не догадался.
·>Руками накидать образец для теста же. Другие догадались давным давно.

В том то и дело, что давным давно — это подход 90х...00х
Сейчас можно иначе

P>>Ну тогда нет гарантии, что внешние консумеры вообще чтото вызвать смогут. Они то будут исползовать опен апи, а ты протестировал абы как.
P>>Итого — а хрен его знает, чего ждать у них.
·>Как они будут использовать опенапи? Вот пишут они клиента на... ээ.. допустим go. Куда они впихнут спеку, чтобы её использовать?

Очевидно — для го есть генератор который их устраивает. Для них это нормально, т.к. для них цикл разработки и так медленный, они получают обновления со скоростью наших релизов, можно не париться.
А вот у нас иначе — изменения апи во время разработки проходят много итераций, и здесь хочется получить результат максимально быстро
1. фиксанул сервис, проверил, что работает
2. обложил аннотациями, и получил апи
Теперь всё, кто зависит от этого сервиса вынуждены перекомпилироватся, и никакими хитростями это не получится обойти.
А если schema-first, то все иначе — пол-проекта работают как ни в чем не бывало "а у нас и так палит" и в итоге фиаско

P>>1. есть тулы для работы с опен апи, для тестов
·>Ну это не для них, а для вас. Демка, чтобы сейлзы могли впаривать ваш эээ... продукт. В свой код они не смогут встроить, т.к.:

Медленно — у них. Как работают сейлзы — ты не в курсе, не надо тащить отсебятину.

P>>2. они могут использовать какой угодно генератор, мы не делаем предположений. Вдруг у них перл — это их зона ответственности.
·>Ты сам заявил, что не смогут: "опробовали, получили отстой.". Ночной Смотрящий тоже говорил, что пробовал с тем же результатом.

Рандомную спеку — нет, не смогут. А вот выхлоп нашего генератора — смогут, т.к. он автоматически валидирует многие вещи, указывает, что должно, а чего не должно быть.
Соответственно, новых девелоперов не надо учить "как именно нужно писать спеку что бы у тех ребят было всё хорошо".

P>>От апи есть вполне конкретные ожидания. Это часть требований.
·>Так это ничего не докажет. Вы из кода генерите тесты самого кода. Порочный круг.

Не из кода, а из документации.

P>>А раз так, то нужен внятный контроль, автоматический, что может быть, а чего не может быть в апи.
P>>Соответственно, мы берем либу определенную которая выдает простой манифест, который можно скормить почти любому генератору.
·>Задумка хорошая, но не работает.

Работает!

P>>Это уже дело десятое. Главное, что хорошего кодогенератора нет.
·>Куда дели-то? Вот взял я swagger-codegen-cli.jar и сгенерил для https://github.com/googlemaps/openapi-specification всё завелось, и клиента и сервера под спринг и под котлин. Теперь могу спокойно вписывать логику в клиента и наваять местный стаб-сервер для тестов.

Ты сам себя высек — вот эта спека ажно 2.6мб. Судя по контенту — выхлоп какого то сборщика. То есть, товарищи из гугла постарались сгенерить спеку так, что бы её можно было без проблем скармливать генератору.
Наши консумеры поступают ровно так же, как и ты с гугловым апи.

P>>Ну да, и выяснишь, что кодогенератор такое не умеет. Гы гы
·>Кодогенератор умеет не больше, чем есть в спеке. И не меньше.

Гораздо больше, и в этом проблема.

P>>Зачем? Ты хочешь что бы я повторил тот ресерч ? Их тучи, у меня нет желания перебирать десятки либ.
·>И все они gpl и не позволяют шаблоны подправлять? Врёшь.

У разных разные проблемы. Расширяемость, конфигурация, лицензия, стабильность, архитектура выхлопа, фремворк выхлопа, поддерживаемые фичи опенапи.

·>Да что там гадать-то? Очевидно же https://stackoverflow.com/questions/66909557/swashbuckle-is-generating-an-invalid-json-with-system-collections-generic-keyval Схемагенератор же просто и удобно... В апи понаписали генерики, которые swashbuckle переварить не смог и вывалил какашку.

ну ок — генеренный код. Сгенерировали хрень, проблема в том, что работа наот..сь. Такой подход и в ручном исполнении дает паскудство.

Здравствуйте, Pauel, Вы писали:

P>·>Зачем его генерить? Цель теста проверить, что генератор генерит то, что мы ожидаем он должен генерить. Пишем образец и ассертим что результат совпадает с образцом.
P>Написал, покрыл тестами. Баги могут быть, или у тебя и здесь багов не бывает?
P>А раз баги бывают, то как ты будешь детектить, что вдруг сгенерилось не то? Упс!
Ну пофиксишь багу, сгенеришь другое. В чём аргумент-то?

P>А со схемой можно это вопрос решить разными способами.
Какими? И почему эти же способы не подходят для кодогенерации?

P>>>Они сами просят.
P>·>Зачем они просят-то?
P>Используют для генерации, для тестов, итд.
Почему у вас генерация не работает, у Ночного Смотрящего не работает, а у них работает?

P>·>Вот это и положи в expected output теста.
P>Так себе идея. Кодогенератору надо дать выхлоп в виде пакета, модуля или даже целого солюшна, с депенденсами, помкой и прочими приседаниями. Соответственно, сравнивать не кусочек текста, а дерево файлов. И это уже не хухры мухры — долго и муторно.
Честно говоря, не вижу проблемы. Пройтись по списку файлов и сделать сравнение — вопрос десятки строчек кода. Особенно с учётом того, что выхлоп можно проверить банально запустив билд и тест солюшена. Способы валидации сгенерённой схемы — ты так и не рассказал. Вот создатели swashbuckle не смогли осилить вменяемую схемогенерацию. А в том же swaggergen около сотни кодогенераторов в различные яп и платформы.

P>·>А тест будет просто наоборот:
P>Крайне хрупкий тест, т.к. если ты вдруг поменял мелочь, у тебя все тесты вдруг упали, и надо обновлять не фрагменты кода, а вообще всё.
Почему все? В сгенерённом коде несколько вполне определённых частей, которые меняются максимум при выходе новой версии openapi стандарта.

P>Например — твой генеренный код использует кое какие депенденсы. Упс — часть из них протухла. Гы-гы, меняй шаблоны. Фиксай все файлы заготовок для тестов.
Образец генерённого кода — обычный код. Его можно открыть в IDE и отрефакторить.

P>В этом плане схема вещь достаточно стабильная, меняется куда реже, чем генератор кода и шаблоны к нему.
Верно, если ты под схемой полагаешь стандарт схемы. Ибо набор метаданных и аннотаций ЯП ничем не ограничен, ничем не валидируется. А openapi по сравнению с c# — донельзя примитивен. Язык разметки по определению проще общего языка программирования. Поэтому распаристь редкоменяемую схему и сгенерить примитивный код — гораздо проще, чем парсить код, который постоянно меняется и туда кто угодно может вписывать что угодно.

P>>>Наша нормально парсится.
P>·>Что они будут делать со схемой?
P>Подкидывают своим тулам, для тестов или генерации клиентов под свои платформы.
Ок. Т.е. почему-то у них кодогенерация работает, у вас нет, у Ночного Смотрящего тоже нет. Почему?

P>>>Я не могу понять твои идеи. Почему только интерфейс? Нужен весь клиентский код.
P>·>Аналог твоего "class Api" с навешанными аннотациями. Только интерфейс вместо класса.
P>Алё — ты читаешь вообще? — этот класс и есть полнофункциональный клиент, и он же есть описание АПИ.
Генерируемый интерфейс — это отражение спеки — сигнатуры методов, аннотации, маппинги, помимо интерфейса ещё дто-шки.
У интерфейса будет две реализации — одна на сервере (тот самый твой class API, но без аннотаций и прочего шлака, банальный implements) и вторая реализация на клиенте — сгенерённая, которая вызовы методов сериализует в rest. См. у меня тут

Автор: ·
Дата: 14.12.22

примерчик.

P>Вот так вызывается
P>return api.method('an id');
Это только клиентская часть. Скучно. И неясно как ты клиентам предлагаешь мокать в юнит-тестах этот твой "class API".

P>И для этого мне все что нужно — только описать апи, как выше.
Угадай, что значит последняя буква в аббревиатуре "апи".

P>>>Ну то есть, ты собрался и генерить код, и тут же его руками накидать, что бы он в юнит тестах был. Мощно! Как это я не догадался.
P>·>Руками накидать образец для теста же. Другие догадались давным давно.
P>В том то и дело, что давным давно — это подход 90х...00х
P>Сейчас можно иначе
Да и тогда делали иначе. Генерили из visual basic какой-нибудь idl.

P>>>Ну тогда нет гарантии, что внешние консумеры вообще чтото вызвать смогут. Они то будут исползовать опен апи, а ты протестировал абы как.
P>>>Итого — а хрен его знает, чего ждать у них.
P>·>Как они будут использовать опенапи? Вот пишут они клиента на... ээ.. допустим go. Куда они впихнут спеку, чтобы её использовать?
P>Очевидно — для го есть генератор который их устраивает. Для них это нормально, т.к. для них цикл разработки и так медленный, они получают обновления со скоростью наших релизов, можно не париться.
P>А вот у нас иначе — изменения апи во время разработки проходят много итераций, и здесь хочется получить результат максимально быстро
P>1. фиксанул сервис, проверил, что работает
P>2. обложил аннотациями, и получил апи
P>Теперь всё, кто зависит от этого сервиса вынуждены перекомпилироватся, и никакими хитростями это не получится обойти.
P>А если schema-first, то все иначе — пол-проекта работают как ни в чем не бывало "а у нас и так палит" и в итоге фиаско
Я не понимаю почему тот же подход не применим. Поменяли схему — все вынуждены перекомпилиться, ведь это даёт гарантированную совместимость.

P>>>2. они могут использовать какой угодно генератор, мы не делаем предположений. Вдруг у них перл — это их зона ответственности.
P>·>Ты сам заявил, что не смогут: "опробовали, получили отстой.". Ночной Смотрящий тоже говорил, что пробовал с тем же результатом.
P>Рандомную спеку — нет, не смогут. А вот выхлоп нашего генератора — смогут, т.к. он автоматически валидирует многие вещи, указывает, что должно, а чего не должно быть.
Или не указывает, т.к. может быть столько всего, что распознать может быть, что не может — неалгоритмизируемая задача, даже теоретически. В случае спеки у тебя явно задано, что быть может. Всё что не по спеке — не может.

P>Соответственно, новых девелоперов не надо учить "как именно нужно писать спеку что бы у тех ребят было всё хорошо".
Ну вот тех ребят, создающих swashbuckle и ребят из moedelo никто и не научил.

P>>>От апи есть вполне конкретные ожидания. Это часть требований.
P>·>Так это ничего не докажет. Вы из кода генерите тесты самого кода. Порочный круг.
P>Не из кода, а из документации.
Какой документации?

P>>>А раз так, то нужен внятный контроль, автоматический, что может быть, а чего не может быть в апи.
P>>>Соответственно, мы берем либу определенную которая выдает простой манифест, который можно скормить почти любому генератору.
P>·>Задумка хорошая, но не работает.
P>Работает!
Как минимум — не всегда работает. Например, у Ночного Смотрящего.

P>>>Это уже дело десятое. Главное, что хорошего кодогенератора нет.
P>·>Куда дели-то? Вот взял я swagger-codegen-cli.jar и сгенерил для https://github.com/googlemaps/openapi-specification всё завелось, и клиента и сервера под спринг и под котлин. Теперь могу спокойно вписывать логику в клиента и наваять местный стаб-сервер для тестов.
P>Ты сам себя высек — вот эта спека ажно 2.6мб. Судя по контенту — выхлоп какого то сборщика. То есть, товарищи из гугла постарались сгенерить спеку так, что бы её можно было без проблем скармливать генератору.
P>Наши консумеры поступают ровно так же, как и ты с гугловым апи.
Не понял где. Это целый репо, с исходниками спеки.
Суть в том, что спека пишется по исходному стандарту openapi. И поэтому получается стандартной по определению. При схемогенерации, нужно парсить мету вашего конкретного кода, который пишется как попало. Поэтому требуется распознавать что понаписаное в шарпе ложится в стандарт. Это гораздо сложнее. Вы можете в шарпе писать как попало, реализуя любые свои идеи. Но если они не выражаются в виде вменяемой операпи спеки, то возникнут проблемы, притом не у вас непосредственно, а у ваших клиентов.

P>>>Ну да, и выяснишь, что кодогенератор такое не умеет. Гы гы
P>·>Кодогенератор умеет не больше, чем есть в спеке. И не меньше.
P>Гораздо больше, и в этом проблема.
Нет, больше просто неоткуда брать, стандарт очень ограничен. Например, в опенапи нет генериков, поэтому ты банально не сможешь вписать ничего такого. В шарпе генерики есть. И если пытаться потом из этого что-то нагенерить — будут проблемы. В этом и суть dsl — явно ограничить возможности, чтобы гарантировать юзабельность.

P>>>Зачем? Ты хочешь что бы я повторил тот ресерч ? Их тучи, у меня нет желания перебирать десятки либ.
P>·>И все они gpl и не позволяют шаблоны подправлять? Врёшь.
P>У разных разные проблемы. Расширяемость, конфигурация, лицензия, стабильность, архитектура выхлопа, фремворк выхлопа, поддерживаемые фичи опенапи.
По твоему заявлению у ваших клиентов таких проблем нет. Почему?

P>·>Да что там гадать-то? Очевидно же https://stackoverflow.com/questions/66909557/swashbuckle-is-generating-an-invalid-json-with-system-collections-generic-keyval Схемагенератор же просто и удобно... В апи понаписали генерики, которые swashbuckle переварить не смог и вывалил какашку.
P>ну ок — генеренный код. Сгенерировали хрень, проблема в том, что работа наот..сь. Такой подход и в ручном исполнении дает паскудство.
Ок, так и запишем swashbuckle сделан наот..сь.