История изменений

Нет, меня спросили «как», а я ответил, что тестирую. Зачем объяснять детали, если это индивидуально:

Запросы можно просто валидировать вообще без бд если запросы, как у ТСа, очень зависят от количества кнопок на форме, то, очевидно, ему нужно не валидировать, а убеждаться в их корректности.

можно тестировать каждый по-отдельности, можно функционально, а ещё у тебя как бы БД, тут уже и интеграционными тестами попахивать

а какая разница, как ты тесты назовешь? мне важно, чтобы работало, а не чтоб название подходило :)

Как именно ты тестируешь? Загонятьешь в бд сгенерированный набор данных, копию живых данных?

опять же, какая разница? он же не спрашивает о конкретном случае, ему интересно узнать, какие методики в целом позволяют избежать ошибок в проде. А если у тебя такие тесты, которые не умеют генерировать правдоподобные данные, то ты просто аматор.

Можно выбирать данные, модно ничего тне выбирать, а просто удостовериться, что запрос корректный

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

Можно писать стратегию

Ты что, аутсорсер? Говори нормально.

БД можно эталонную иметь для тестов, а можно запускать и набивать в контейнере на раз.

Что это за шарага, в которой для тестов централизованная БД? У любого разработчика должна быть возможность одной командой поднять все нужные компоненты, 2020-й год на дворе.

кривой запрос может быть и валидным

Что значит «кривой»? Если это опечатка или неправильная склейка строк, или параметры перепутаны - это все должно отлавливаться тестами.

Нет детальных рецептов на любой конкретный случай, есть универсальное понятие тестирования, которое покрывает требования к продукту. Когда кто-то начинает выебываться и говорить «слишком общие слова», начинает пахнуть школой СНГ-аутсорса, когда программисты думают не в терминах решения проблем, а в терминах названий методов. Пока не поздно, найди нормальную работу, найди команду, где из тебя дурь выбьют, потом еще спасибо скажешь.

Нет, меня спросили «как», а я ответил, что тестирую. Зачем объяснять детали, если это индивидуально:

Запросы можно просто валидировать вообще без бд если запросы, как у ТСа, очень зависят от количества кнопок на форме, то, очевидно, ему нужно не валидировать, а убеждаться в их корректности.

можно тестировать каждый по-отдельности, можно функционально, а ещё у тебя как бы БД, тут уже и интеграционными тестами попахивать

а какая разница, как ты тесты назовешь? мне важно, чтобы работало, а не чтоб название подходило :)

Как именно ты тестируешь? Загонятьешь в бд сгенерированный набор данных, копию живых данных?

опять же, какая разница? он же не спрашивает о конкретном случае, ему интересно узнать, какие методики в целом позволяют избежать ошибок в проде. А если у тебя такие тесты, которые не умеют генерировать правдоподобные данные, то ты просто аматор.

Можно выбирать данные, модно ничего тне выбирать, а просто удостовериться, что запрос корректный

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

Можно писать стратегию Ты что, аутсорсер? Говори нормально.

БД можно эталонную иметь для тестов, а можно запускать и набивать в контейнере на раз.

Что это за шарага, в которой для тестов централизованная БД? У любого разработчика должна быть возможность одной командой поднять все нужные компоненты, 2020-й год на дворе.

кривой запрос может быть и валидным

Что значит «кривой»? Если это опечатка или неправильная склейка строк, или параметры перепутаны - это все должно отлавливаться тестами.

Нет детальных рецептов на любой конкретный случай, есть универсальное понятие тестирования, которое покрывает требования к продукту. Когда кто-то начинает выебываться и говорить «слишком общие слова», начинает пахнуть школой СНГ-аутсорса, когда программисты думают не в терминах решения проблем, а в терминах названий методов. Пока не поздно, найди нормальную работу, найди команду, где из тебя дурь выбьют, потом еще спасибо скажешь.