Comments 20
Спасибо за идею для следующей статьи.
Допустим, разработчик MariaDB внес изменения и сломал то, что раньше работало. В нашем примере это расчет среднего значения. И тест тогда упадет.
При всем уважении к Вам как автору, хотелось бы отметить, что если разработчик MariaDB внес изменения, которые сломали SQL-операции в его СУБД, и при этом выкатил это без тестов или со сломанными тестами, то: 1) на это нам с Вами тяжело повлиять, т.к. это внешний продукт, который разрабатываем совсем не мы 2) с высокой долей вероятности это заметят до того, как мы напишем\запустим тест, ибо у проекта достаточная аудитория 3) видимо, если разработчики допускают подобное, тем более настолько регулярно, что за ними надо перепроверять базовые вещи, то, кажется, имеет смысл задуматься о переходе на другую СУБД, с репутацией получше.
В целом, статья была бы значительно более интересной, если бы пример был посложнее, например, сравнительный тест поведения разных СУБД в одних и тех же условиях, тест какой-то из уникальных фич MariaDB, тест, покрывающий какие-то пограничные условия или история баги, которая нашлась случайно на каком-то кейсе и т.д.
Пока, к сожалению, полезности очень не хватает.
Статья как раз и предназначалась для тех кто хотел бы попробовать потестить именно саму базу данных, как сервис.
Опишите, пожалуйста, что для Вас "база данных как сервис".
Для меня DBaas это то, что предоставляют облачные провайдеры - готовая БД, которая за меня настроена и админится, а управление осуществляется кликами в интерфейсе, а не запросами в команду ДБА. Где с меня снимается головная боль, связанная с железом, стабильностью и прочее.
https://habr.com/ru/company/vk/blog/568478/ - здесь более подробно.
И в этих БД не надо тестить SQL-операции по причинам, которые я указал выше, это уже готовые, чужие решения, у которых есть свои тестеры.
Свои тестеры, вот о них как раз и речь.
Вы один из них? Моё почтение.
Неужели Вам не нашлось что рассказать, кроме достаточного простого SQL-кода и вольного осмысления документации?
Вот пример от Сергея Бронникова, который занимался тестированием СУБД Tarantool - https://habr.com/ru/company/vk/blog/584864/
Уверен, что и у Вас есть, что рассказать такого, что будет полезнее текущего материала.
Поставьте, пожалуйста, хотя бы тег "для начинающих" или вроде того. А database development лучше заменить.
И прошу простить за то, что мог показаться токсичным, просто достаточно много примеров статей ради статей, в которых минимум или ноль полезной информации, а заголовок Вашего материала задел за живое, т.к. близок к личному опыту и поэтому ожидалась чуть более интересная история.
эти тесты работают путём сравнения результатов теста с заранее записанным эталонным результатом (тем самым sergei.result). если совпало — тест считается успешным.
Я всё пытаюсь понять, какое отношение статья имеет к тестированию бекенда и у меня не выходит.
Для того, чтобы проверить коректность записи введенных данных на фронтенде в базу данных бэкенда метод, описанный в статье, не подойдёт. Для тестирования корректности схемы тоже.
Я вообще не могу представить, где в разработке веб сервисов могут встретиться такие тесты. Вы такое видели?
Впринципе необходимость делать дебаг сборку намекает, что таким образом можно отлаживать какие-то сложные запросы, чтобы понять как их оптимизировать, но это уже не тестирование.
Вот я тоже прочитал и первым делом подумал, а как это можно внедрить на проекте? Вот у меня есть уже БД, как это сделать на ней? Или можно тестировать только в дебаг режиме?
На самом деле вступления не совсем удачное. Статья о том как тестировать базы данных как сервис на примере MariaDB. Но это так же применимо и к другим типам баз данных. Ведь то чем мы пользуемся тоже необходимо сначала протестировать.
На самом деле вступления не совсем удачное.
Тогда имеет смысл поправить текст
Статья о том как тестировать базы данных как сервис на примере MariaDB.
Ну вы где-нибудь видели, чтобы кто-то вот так тестировал базу данных как сервис? Если видели, то не могли бы вы описать, что это за компания, какого рода услуги она предоставляет, как использует такие тесты? Я не против, если вы эту компанию выдумаете, но хотелось бы понять, чем она может заниматься, что там нужны такие тесты.
Но это так же применимо и к другим типам баз данных.
Возможно в других базах данных тоже есть дебаг режим, в котором есть тулинг для вот таких тестов. Но кто, кроме разработчиков этих СУБД будет эти тесты запускать?
Ведь то чем мы пользуемся тоже необходимо сначала протестировать.
На что протестировать? На корректность реализации SQL? Такие тесты как правило делают сами разработчики СУБД. А если нужно протестировать подойдёт ли эта база данных для вашего приложения, то это делается совсем по другому.
Сомневаюсь что разработчики СУБД сами тестируют. Для этого существуют тестеры с совсем другой зарплатой.
Сомневаюсь что разработчики СУБД сами тестируют.
Я правильно понимаю, что вы сомневатесь, что разработчики СУБД тестируют корректность реализации SQL в той СУБД, которую они разрабатывают?
Для этого существуют тестеры с совсем другой зарплатой.
А эти тестеры работают в той компании, которая разрабатывает СУБД?
тестируют, не сомневайтесь. и, скажу вам по секрету, зарплата не совсем другая :)
Тестирование базы данных