Общебанковские сообщества - первый движ направленный на выравнивание инженерных практик, который не вызывает отторжения. Поголовные DevOps, t-shape, платформы - все насаждалось. Ни кто не знает как правильно, ничего не работает, но НАДО, а потом переделать (намерения всегда благие, но вот исполнение и реакция...). А тут прям бальзам на душу. Хочешь - участвуй! У нас есть готовые решения, приходи и бери. Костылируй сам, ищи единомышленников, публикуй решения для остальных не в пределах своего трайба или направления, а на всех разрабов. А не хочешь - просто не делай.
В статье количество схем в пуле 10, без проблем сделать больше, просто этого хватает. В бою (не для статьи) используется не по 1 схеме на тест, а по несклько — в метаданных перечисляются схемы с разными префиксами, но одинаковыми id-суффиксами: Схема на заполнение БД и схема "пользователя без таблиц", куда только гранты на чтение выдаются.
Запускать параллельно тесты в рамках одной сборки — потратить время на создание структуры через liquibase, это накладнее по производительности. Сейчас по производительности бьет халатное отношение к ней. Если мне надо протестировать запрос на 1000 записей, у меня будет 1000 операций вставки. Объединение в batch сократило воемя выполнения одного из таких тестов с 17 сек до 1. Так же с ростом changelog-а будет увеличиваться время первого наката структуры.
Реализовывал схожую систему, но не для юнит тестирования, а для функционального (чтобы не соврать с терминологией — программа является черным ящиком, тесты общаются с ней исключительно через UI). Необходимо было протестировать множество отчетов на разных наборах данных.
Остановился на таком формате тестов — тестовый скрипт, содержащий набор данных, настроек и названия отчетов. При первом прогоне собирались эталонные отчеты. Эталоны проверялись руками, или не проверялись вовсе (когда количество данных было запредельным и смысл был только в отлове изменений, суть есть регрессионное тестирование). При последующих запусках эталон и текущий отчет скармливались diff-у и при наличии изменений тест помечался как имеющий различия, но не упавший. Тест падал только при невозможности выпустить отчет или ввести данные.
Для ручного тестирования, вместо того чтобы выполнять ввод исходных данных и выпуск отчета, было проще написать новый тест (не содержащий эталонных данных), запустить его, подождать пару часов (думаете отчеты быстро выпускаются? И как только раньше руками тестировал...), получить результаты, проверить и добавить новый тест в базу тестов.
Какая жалость, я рассчитывал назвать алгоритм своим именем… </:-)>
Определенно здорово, что алгоритмы над строками находят своё применение в биоинформатике и в других областях. Я не увдел статей на русском языке, описывающих этот алгоритм, потому ориентировался на приведенную вами ссылку. По ней алгоритм больше схож с исходным алгоритмом Вагнера-Фишера с инвертированными операциями. Т.е. путь будет искаться не по минимальному значению в ячейке, а по максимальному. Совпадение символов даст не 0 прирост, а максимальный 2. И "технические" первые строка и столбец заполняются не индексом строки/столбца, а нулём.
<:-)> Исходя из вышесказанного, у меня еще есть шанс попасть в историю!
Тестирование удачливости флешек.
Требуется: группа испытателей, флешки с разным дизайном, стол, под которым стоит комп с USB портами расположенными на задней стенке.
Процесс: испытатели по одному, на ощупь, пытаются вставить флешку в USB-порт компьютера, стоящего под столом.
Подсчитывается количество необходимых переворачиваний накопителя перед правильной вставкой в порт.
Процент правильного попадания с первого, второго, третьего раза — X1,X2,X3 соответственно.
X1 > 50%, lucky pass
X1 > X2 и X3, X2 > X3, usability warning
X1 > X2 и X3, X2 < X3, lucky warning
X1 < X2 или X3, lucky fail
Флешка вставлена с 4 или более раза, её удалось вставить не той стороной или сломать, при попытке вставить вывалилась из руки, испытатель выругался в процессе вставки или стукнулся головой вставая из под стола — test crash.
Как мы в Сбере формировали сообщество практики по автоматизации DevOps CI/CD
Общебанковские сообщества - первый движ направленный на выравнивание инженерных практик, который не вызывает отторжения. Поголовные DevOps, t-shape, платформы - все насаждалось. Ни кто не знает как правильно, ничего не работает, но НАДО, а потом переделать (намерения всегда благие, но вот исполнение и реакция...). А тут прям бальзам на душу. Хочешь - участвуй! У нас есть готовые решения, приходи и бери. Костылируй сам, ищи единомышленников, публикуй решения для остальных не в пределах своего трайба или направления, а на всех разрабов. А не хочешь - просто не делай.
Подружить CI, unit-тесты и базу данных
В статье количество схем в пуле 10, без проблем сделать больше, просто этого хватает. В бою (не для статьи) используется не по 1 схеме на тест, а по несклько — в метаданных перечисляются схемы с разными префиксами, но одинаковыми id-суффиксами: Схема на заполнение БД и схема "пользователя без таблиц", куда только гранты на чтение выдаются.
Подружить CI, unit-тесты и базу данных
Запускать параллельно тесты в рамках одной сборки — потратить время на создание структуры через liquibase, это накладнее по производительности. Сейчас по производительности бьет халатное отношение к ней. Если мне надо протестировать запрос на 1000 записей, у меня будет 1000 операций вставки. Объединение в batch сократило воемя выполнения одного из таких тестов с 17 сек до 1. Так же с ростом changelog-а будет увеличиваться время первого наката структуры.
Подружить CI, unit-тесты и базу данных
Я описывал решение проблемы, когда тесты запускаются на jenkins параллельно (проверяют pull-реквесты) и каждому нужна своя база.
Подружить CI, unit-тесты и базу данных
В статье и описано не поднятие бд на каждый тест, а выделение схемы перед запуском всех тестов с последующим освобождением.
Подружить CI, unit-тесты и базу данных
Embedded решений я ни 1 не видел. Есть H2 поддерживающая диалект оракла, но сильно не полноценно.
А пусть тесты сами себя и поддерживают
Остановился на таком формате тестов — тестовый скрипт, содержащий набор данных, настроек и названия отчетов. При первом прогоне собирались эталонные отчеты. Эталоны проверялись руками, или не проверялись вовсе (когда количество данных было запредельным и смысл был только в отлове изменений, суть есть регрессионное тестирование). При последующих запусках эталон и текущий отчет скармливались diff-у и при наличии изменений тест помечался как имеющий различия, но не упавший. Тест падал только при невозможности выпустить отчет или ввести данные.
Для ручного тестирования, вместо того чтобы выполнять ввод исходных данных и выпуск отчета, было проще написать новый тест (не содержащий эталонных данных), запустить его, подождать пару часов (думаете отчеты быстро выпускаются? И как только раньше руками тестировал...), получить результаты, проверить и добавить новый тест в базу тестов.
Readme Driven Development
Полнотекстовый нечеткий поиск с использованием алгоритма Вагнера-Фишера
Определенно здорово, что алгоритмы над строками находят своё применение в биоинформатике и в других областях. Я не увдел статей на русском языке, описывающих этот алгоритм, потому ориентировался на приведенную вами ссылку. По ней алгоритм больше схож с исходным алгоритмом Вагнера-Фишера с инвертированными операциями. Т.е. путь будет искаться не по минимальному значению в ячейке, а по максимальному. Совпадение символов даст не 0 прирост, а максимальный 2. И "технические" первые строка и столбец заполняются не индексом строки/столбца, а нулём.
<:-)> Исходя из вышесказанного, у меня еще есть шанс попасть в историю!
Полнотекстовый нечеткий поиск с использованием алгоритма Вагнера-Фишера
Полнотекстовый нечеткий поиск с использованием алгоритма Вагнера-Фишера
Нам нужны ваши мозги
Требуется: группа испытателей, флешки с разным дизайном, стол, под которым стоит комп с USB портами расположенными на задней стенке.
Процесс: испытатели по одному, на ощупь, пытаются вставить флешку в USB-порт компьютера, стоящего под столом.
Подсчитывается количество необходимых переворачиваний накопителя перед правильной вставкой в порт.
Процент правильного попадания с первого, второго, третьего раза — X1,X2,X3 соответственно.
X1 > 50%, lucky pass
X1 > X2 и X3, X2 > X3, usability warning
X1 > X2 и X3, X2 < X3, lucky warning
X1 < X2 или X3, lucky fail
Флешка вставлена с 4 или более раза, её удалось вставить не той стороной или сломать, при попытке вставить вывалилась из руки, испытатель выругался в процессе вставки или стукнулся головой вставая из под стола — test crash.
Как выбрать рабочий ноутбук (февраль, 2016)