Тесты тестам рознь. Они бывают очень разные.
Все зависит от того,
что именно Вы хотите протестировать.
Могут быть тесты производительности. Они проверяют что скорость выполнения кода/приложения/запроса удовлетворяет определенному значению.
Могут быть нагрузочные тесты. Они проверяют что приложение/система держит определенные нагрузки.
Могут быть тесты, которые проверяют систему на предмет соответствия определенным стандартам безопасности (PCI compliance check, к примеру).
В принципе, тесты могут тестировать любой интересующий Вас аспект/метрику кода/приложения/чего-угодно.
Чаще всего тесты пишут, чтобы проверить правильность работы заложенной в приложение бизнес-логики.
Все выше упомянутые случаи имею общую черту - какие-либо ожидания, которые подтверждаются, или не подтверждаются тестами.
Соответственно тесты, как таковые, непосредственно
связаны с понятием спецификации кода/приложения/модуля/чего-угодно. Собственно, в BDD (behavior-driven development) тесты часто так и называют - spec (спеки).
Идея проста и никаких тайн не содержит:
Вы пишете спецификацию, а
тесты доказывают что приложение соответствует спецификации.
Эта идея применяется на любом уровне от самых низкоуровневых модулей, до высокоуровневых частей системы, и самой системы в целом.
Ваша задача не "повалить систему REST api", а удостовериться, что она работает ожидаемым и требуемым образом (что делать должна, и чего не должна). Именно подобные требования и нужно вносить в спецификацию.
Вот очень упрощенная спецификация для Вашего примера:
Допустим если rest_api на вход примет json файл
1. Если на вход ничего не подано, rest_api должен вернуть ошибку 1 (отсутствует тело запроса).
2. Если на вход подан не JSON, rest_api должен вернуть ошибку 2 (некорректный запрос).
3. Если структура JSON не содержит всех необходимых параметров, rest_api должен вернуть ошибку 3 (некорректные параметры).
4. Если передан валидный запрос, rest_api должен вернуть результат в нужном формате.
5. Если передан валидный запрос повторно, rest_api должен вернуть ошибку 4 (файл уже обработан).
Соотвественно, тесты проверяют выполняется ли каждый пункт спецификации.
Основные профиты, которые Вы получаете на выходе:
- у Вас есть формализация требований;
- у Вас есть автоматическое доказательство выполнения требований;
- Вы теперь можете отловить нарушение требований при изменении кода;
- Вы начинаете должным образом задумываться о требованиях вообще.
Все это дает кое-какие гарантии качества конечного продукта, и убирает кучу рутинной работы по повторному тестированию всего и вся.
P.S. Разработка программного обеспечения - самая открытая и прозрачная современная профессия. Ни в какой другой области я не встречал аналогов дотягивающих до open source движения, и такого громадного кол-ва докладов/статей в свободном доступе, где люди охотно делятся опытом и понимаем, такого кол-ва обучающих площадок, такого рвения помогать друг другу становиться лучше в профессиональном плане.
Потому, в следующий раз, прежде чем говорить о "средствах манипуляции" и "пруф-линщиках", откройте глаза, зайдите на тот же Github, где можно вот-так просто взять и посмотреть "как оно делается", не поленитесь почитать "пруф-линки", где тема фундаментально разжевана по полочкам, послушать доклады с конференций. Вам все сообщество ставит большую такую миску с кашей под нос - бери и ешь. Если Вы хотите, чтобы Вам рот открыли, ложку в рот положили, и ещё и челюстью подвигали, - так это делают в детском саду воспитатели.
