gzhegow
@gzhegow
Думал, стану умнее, когда адаптируюсь, но нет

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

Прошу пояснить по какому принципу пишутся юнит тесты под конкретную задачу.

Очень прошу не отвечать "отправлятелей почитать что-нибудь и где-нибудь" и даже "пруф-линщиков" - "типа вот статья на английском в 70 листов, иди изучай"

Мне интересен даже не пример теста какого-то, а сама организация мыслей - что это значит - написать тест, и как это самое значит зависит от задачи. Вот семинар например от разрабов Badoo, где они говорят что нужно писать на каждую функцию 2 теста, и обязательно тесты на REST api.

Моя задача теста получается повалить систему REST api. Но учитывая, что я сам пишу эти тесты, и пишу их под собственный код - я же не предугадаю, каким образом эта система может лечь.

Допустим если rest_api на вход примет json файл - то сразу в голове всплывают проверить mime/тип, проверить расширение, проверить контент файла, поставить защиту на количество запросов с одного ипа в минуту, поставить что-то еще... ну то есть всплывают в голове идеи как модифицировать оригинальный код.

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

Вот в таком ключе хотелось бы общий вид примера увидеть. Даже хорошо если не конкретный код, а именно на языке пояснений - вот дескать rest api, вот метод get, понадобятся такие-то тесты, потому и потому.

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

Так что да поможет мне осознавший пользу единого знания для всех, а не маркетолог, понимающий ценность того, о чем я спрашиваю.
  • Вопрос задан
  • 456 просмотров
Решения вопроса 3
lxsmkv
@lxsmkv
Test automation engineer
когда вы пишите тест вы хотите знать если вдруг что-то пойдет не-так. Вы используете интерфейс, вы уверены что фунцкция этого интерфейса всегда делает то, что обещает по документации? А вы уверены что это будет так завтра и через год? Вы уверены что ваш код правильно реагирует на ответы которые приходят на ваши запросы по API? А как поведет себя код если формат ответа изменится? Все эти "а что-будет если" не из любопытства и духа экспериментаторства а от неизвестности и неуверенности.
Когда ты ставишь свой код на "сигнализацию", стресса и неуверенности становится меньше, а информации больше. Можно проводить операции над кодом (рефакторинг) будучи уверенным, что если заденешь жизненно важный орган тебе об этом заморгает лампочка.
Про ТДД ничего не могу сказать, мне тяжело думать шиворот-навыворот. Стремиться к этому наверно нужно, потому, что если ты можешь начать с тестов то значит спецификация у тебя жесткая, отлично закодокументированая, архитектура четкая - но в жизни к сожалению бывает и иначе, там где сначала пилим как придется, посмотрим что получится, и если это понравится заказчику - доведем до ума.

П.С. помню как-то давно, когда только начинал изучать junit попробовал ради интереса написать на простенький класс-коллекцию тесты. Во-первых их получилось больше, чем мне казалось возможным на первый взгляд. Во-вторых, я не успел отъехать и на пятьсот строк кода, как уже тесты местами покраснели. Значит что-то задел и совершенно не обратил внимания. А казалось ну что можно напортачить в десяти классах. Можно.
Ответ написан
@red-barbarian
Чем больше тестов, тем лучше.
Тесты не гарантируют корректность кода и идей.
Нормальный тест это "тест черной коробки" - мы не знаем как она реализуется, но мы может проверить как она реагирует на воздействия из вне.
Если мы залезли в черную коробку и копаемся внутри, то ранее написанные тесты дают некоторую гарантию, что мы ничего не поломали.

Ну и наконец, если использовать разработку через тестирование, то интерфейс черной коробки получается чаще всего заточены под нужды системы, а не под шаткое понимание образа коробки у программиста.
Ответ написан
Tyranron
@Tyranron
Тесты тестам рознь. Они бывают очень разные.
Все зависит от того, что именно Вы хотите протестировать.
Могут быть тесты производительности. Они проверяют что скорость выполнения кода/приложения/запроса удовлетворяет определенному значению.
Могут быть нагрузочные тесты. Они проверяют что приложение/система держит определенные нагрузки.
Могут быть тесты, которые проверяют систему на предмет соответствия определенным стандартам безопасности (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, где можно вот-так просто взять и посмотреть "как оно делается", не поленитесь почитать "пруф-линки", где тема фундаментально разжевана по полочкам, послушать доклады с конференций. Вам все сообщество ставит большую такую миску с кашей под нос - бери и ешь. Если Вы хотите, чтобы Вам рот открыли, ложку в рот положили, и ещё и челюстью подвигали, - так это делают в детском саду воспитатели.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы