Вообще очень интересный кейс. В целом я бы посмотрел на метрики по сравнению с созданием частичного слепка базы данных. Но стоит понимать, что запуск контейнера тоже операция не моментальная, а еще и достаточно ресурсо затратная и тут тоже вопрос как они все будут жить параллельно в 10-20 инстансов.
Я в свое время такую идею сразу же отбросил, но тогда и докер контейнеры только начинали зарождаться.
По базовым терминам, конечно же, при тестировании логики, если задействован внешний сервис (в данном случае база данных), это является интеграционным тестированием. Но никто не запрещает упростить взаимодействие с ним реализовать все необходимые условия, чтобы эти тесты максимально походили на юнит тестирование. Ну и опять же все зависит от цели тестов. Если приоритет именно в проверке логики нашего кода, в данном случае это запросы в бд, а не проверка логики взаимодействия (поведения при отказе бд, реконнекты, создание подключения, сериализатор и т.д.), то такой тест, в целом, также можно называть юнит.
Хорошая статья, я в свое время тоже занимался этим вопросом https://habr.com/ru/company/arcadia/blog/304322/ но пришел к другому пути. Я для каждого теста создаю копию только необходимой части БД, это позволяет экономить кучу времени и решает некоторые проблемы с параллельным запуском тестов в рамках одного прохода.
Есть еще честные на рынке, но это немного из другого сектора, не банк, краудлендинг. Сами недавно обнаружили такие уловки среди некоторых, были в шоке все) В общем как и везде есть честные компании, а есть не очень. Имен называть не буду чтобы не быть рекламой, но если любопытно могу в личку рассказать.
Тоже таким же занимался, без армии проксей делать нечего сразу же попадаешь в бан и сперва бесконечно решаешь капчи, а потом уже и капчи не дают, сразу блочат) потом 3 месяца не мог гуглом пользоваться
У меня уже очень давно весит в стеше генератор маркдауна, надо бы его освежить и преобразовать в нечто вроде sveltedoc-gen, который будет генерировать и markdown и typings
Например, там еще может быть описание переменных которые получаются из слота, либо какие-то, кастомные типы и интерфейсы. Врятли это получится нагенерировать автоматически.
Звучит как вызов! :D
Проверил, парсит параметры слотов:
Пример компонента и результата
<script>
export let items = [];
</script>
<div>
{#each items as item}
<slot prop={item}></slot>
{:else}
<slot name="empty"></slot>
{/each}
</div>
они уже значительно развитее, чем я смотрел последний раз.
Взяли приоритет на поддержку TS, чтобы пробиться в офф сборку svelte тулов для разработки. А пока что только тут используется
PS. Очень буду рад любым вопросам/багам и фидбекам на гитхабе по поводу библиотеки, моя поделка.
Для уже скомпилированного, jsdoc конечно же уже не подойдет. Я говорил про работу напрямую со svelte компонентами. В основном, работать приходится именно так.
Тайпинги также можно загенировать в авто-режиме на базе той же тулы. Конечно пока, что она не поддерживает TS в компонентах, но скоро планируется, так же как и формирование документации и тайпингов
Статья полезная, спасибо. Не знал про поддержку svelte атрибута в package.json. Обычно ссылаюсь по пути компонента напрямую без реимпорта.
Хочу еще добавить, что документацию полезно писать напрямую внутри компонента, чтобы иметь intellisence в vscode при разработке. А в ридми и т.д. уже вытаскивать автоматически с помощью этой штуки https://www.npmjs.com/package/sveltedoc-parser
В целом версии были совместимы. Т.е. используя свежий рантайм, компоненты со старым должны работать корректно, если они и до этого работали. В основном новые версии привносят только фиксы и новые фичи, старое поведение не меняется.
По крайней мере у меня такой опыт был со svelte
> В общем для какого то быстрого прототипирования еще может пойдет
Там еще и API сверх неудобнный, и куча подбодных камней при запуске, например, требование установленного офиса. Не уверен, что это было бы быстрее и проще библиотеки. С другой стороны если надо поддерживать старые форматы 98 года, то тут уже почти без вариантов, но тут вроде как раз NPOI решает (или какая-то другая библиотека от японцев, точно уже не помню)
Вы ошибаетесь. Большинство библиотек сейчас давным давно ушло от использования COM ибо это медленно. Осталась только старый добрый MicrosoftExcelInterop. Все остальные, в том числе EPPlus используют прямую работу с файлом, даже в режиме стриминга
Я не автор данной статьи, но был опыт работы. В целом принцип взаимодействия между этими двумя библиотеками не отличается, но EPPlus работает чуть пошустрее. Можно тут ознакомиться с моими тестами производительности https://m.habr.com/ru/company/arcadia/blog/498032/
В принципе это тот же цикл, только развернутый вручную. Интересно смог ли ты таким способом превзойти оптимизацию компилятора в сравнении с циклом. Ну и в сравнении со встроенной функцией тоже интересно посмотреть. Без этого это так, детское развлечение)
Вообще очень интересный кейс. В целом я бы посмотрел на метрики по сравнению с созданием частичного слепка базы данных. Но стоит понимать, что запуск контейнера тоже операция не моментальная, а еще и достаточно ресурсо затратная и тут тоже вопрос как они все будут жить параллельно в 10-20 инстансов.
Я в свое время такую идею сразу же отбросил, но тогда и докер контейнеры только начинали зарождаться.
У меня есть подробное исследование с конкретными примерами и цифрами, если вам интересно https://habr.com/ru/company/arcadia/blog/304322/
По базовым терминам, конечно же, при тестировании логики, если задействован внешний сервис (в данном случае база данных), это является интеграционным тестированием. Но никто не запрещает упростить взаимодействие с ним реализовать все необходимые условия, чтобы эти тесты максимально походили на юнит тестирование. Ну и опять же все зависит от цели тестов. Если приоритет именно в проверке логики нашего кода, в данном случае это запросы в бд, а не проверка логики взаимодействия (поведения при отказе бд, реконнекты, создание подключения, сериализатор и т.д.), то такой тест, в целом, также можно называть юнит.
Хорошая статья, я в свое время тоже занимался этим вопросом https://habr.com/ru/company/arcadia/blog/304322/ но пришел к другому пути. Я для каждого теста создаю копию только необходимой части БД, это позволяет экономить кучу времени и решает некоторые проблемы с параллельным запуском тестов в рамках одного прохода.
Спустя долгосрочный перерыв вышло продолжение данной статьи - Разработка системы тестирования SQL запросов. Часть 2
Учитывая что подпись автора говорит, что он разработчик DL и NLP, то вполне вероятно так и есть)
Есть еще честные на рынке, но это немного из другого сектора, не банк, краудлендинг. Сами недавно обнаружили такие уловки среди некоторых, были в шоке все) В общем как и везде есть честные компании, а есть не очень. Имен называть не буду чтобы не быть рекламой, но если любопытно могу в личку рассказать.
Тоже два интроверта сделали 2д портал на варкрафте :D
https://youtu.be/UU1v-Dtuo6Q
ПС. На столько интроверты, что готовился написать коммент почти полгода
Тоже таким же занимался, без армии проксей делать нечего сразу же попадаешь в бан и сперва бесконечно решаешь капчи, а потом уже и капчи не дают, сразу блочат) потом 3 месяца не мог гуглом пользоваться
У меня уже очень давно весит в стеше генератор маркдауна, надо бы его освежить и преобразовать в нечто вроде sveltedoc-gen, который будет генерировать и markdown и typings
Звучит как вызов! :D
Проверил, парсит параметры слотов:
PS. Очень буду рад любым вопросам/багам и фидбекам на гитхабе по поводу библиотеки, моя поделка.
Тайпинги также можно загенировать в авто-режиме на базе той же тулы. Конечно пока, что она не поддерживает TS в компонентах, но скоро планируется, так же как и формирование документации и тайпингов
Статья полезная, спасибо. Не знал про поддержку svelte атрибута в package.json. Обычно ссылаюсь по пути компонента напрямую без реимпорта.
Хочу еще добавить, что документацию полезно писать напрямую внутри компонента, чтобы иметь intellisence в vscode при разработке. А в ридми и т.д. уже вытаскивать автоматически с помощью этой штуки https://www.npmjs.com/package/sveltedoc-parser
В целом версии были совместимы. Т.е. используя свежий рантайм, компоненты со старым должны работать корректно, если они и до этого работали. В основном новые версии привносят только фиксы и новые фичи, старое поведение не меняется.
По крайней мере у меня такой опыт был со svelte
Там еще и API сверх неудобнный, и куча подбодных камней при запуске, например, требование установленного офиса. Не уверен, что это было бы быстрее и проще библиотеки. С другой стороны если надо поддерживать старые форматы 98 года, то тут уже почти без вариантов, но тут вроде как раз NPOI решает (или какая-то другая библиотека от японцев, точно уже не помню)
Вы ошибаетесь. Большинство библиотек сейчас давным давно ушло от использования COM ибо это медленно. Осталась только старый добрый MicrosoftExcelInterop. Все остальные, в том числе EPPlus используют прямую работу с файлом, даже в режиме стриминга
Я не автор данной статьи, но был опыт работы. В целом принцип взаимодействия между этими двумя библиотеками не отличается, но EPPlus работает чуть пошустрее. Можно тут ознакомиться с моими тестами производительности https://m.habr.com/ru/company/arcadia/blog/498032/
Читать и в конце увидеть рекламу, весь текст только ради одной строчки рекламы, разочарование(
В принципе это тот же цикл, только развернутый вручную. Интересно смог ли ты таким способом превзойти оптимизацию компилятора в сравнении с циклом. Ну и в сравнении со встроенной функцией тоже интересно посмотреть. Без этого это так, детское развлечение)