Является ли плохой практикой включение в запросы полей, которые будут работать только в определенных средах?

Я видел похожие вопросы, но в этом случае код, развернутый на всех этапах (local, dev, staging, prod), будет одинаковым.

Идея заключается в том, чтобы иметь специальное поле в одном конкретном запросе, что-то вроде isTest, которое позволит определенной конечной точке (потребляемой веб-клиентом) выполнить действие, которое в противном случае будет неудачным. BE-сервер, получая это поле, также проверяет, является ли среда тестовой (т.е. не prod), чтобы позволить этому произойти.

Идея заключается в том, чтобы очистить некоторые данные из нашей службы, которые имеют некоторые валидации, которые обычно предотвращают их удаление. Но поскольку это тестовая среда и эти данные принадлежат автоматизированным тестовым учетным записям, мы хотим отменить эти валидации и очистить их.

Я не против добавить эту возможность, она не совсем чистая, но я не вижу никаких реальных проблем. Есть какие-нибудь мысли?

EDIT: немного больше информации о ситуации

У нас есть конечная точка DeleteResource, которая может быть вызвана веб-клиентом. В некоторых сценариях этот процесс может быть завершен успешно, но в некоторых - нет. Это происходит потому, что существуют определенные проверки, что когда ресурс прошел через определенные этапы процесса, он больше не может быть удален (по юридическим причинам и т.д.). Итак, если это запрос на удаление

DELETE /resource/id/
{
  ... // some fields
}

мы хотим добавить поле к этому запросу, чтобы оно имело следующий вид

{
  isTest boolean
  ... // some fields
}

чтобы сервер BE знал, что если этот булево значение истинно и сервер работает в среде staging, то эта валидация будет отменена и ресурс будет успешно удален.

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

В целом, есть ли причина, по которой вы не используете свежие тестовые среды для каждого запуска? Вы фактически добавляете еще одну несвязанную зависимость между каждым запуском теста: результаты предыдущих тестов могут повлиять на результаты последующих.

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

Редактировать:

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

Это более простое решение, поскольку очистка данных происходит отдельно от работающей системы.