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

Question

[Григорий Васильков]

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

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

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

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

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

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

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

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

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

Comments

[Григорий Васильков]

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

[Григорий Васильков]

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

[Григорий Васильков]

Вы много выёбуетесь. Вы считаете что вы понимаете, и умеете гуглить. Но как вы знаете, что то что вы делаете и есть умение гуглить и понимание? Вы всего лишь так думаете и не упускаете возможность выйти и попиздеть, не сказав ничего, но заставив всех что-то делать на почве испытываемых эмоций от того, что они не соответствуют вашему пониманию "правильного человека". Кто ты, а кто мир? В вашей тени мира уже не видно.

Answer 1

[Alexej Simakov]

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

П.С. помню как-то давно, когда только начинал изучать junit попробовал ради интереса написать на простенький класс-коллекцию тесты. Во-первых их получилось больше, чем мне казалось возможным на первый взгляд. Во-вторых, я не успел отъехать и на пятьсот строк кода, как уже тесты местами покраснели. Значит что-то задел и совершенно не обратил внимания. А казалось ну что можно напортачить в десяти классах. Можно.

Comments

[Григорий Васильков]

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

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

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

[Григорий Васильков]

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

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

Пожалуйста, прокомментируйте.

[Alexej Simakov]

Григорий Васильков: не придумали пока такой методики которая позволяет писать безошибочный код :) само слово юнит как бы намекает что мы покрываем тестами программную единицу. Чтобы когда возникнет проблема можно было быстрее сузить круг поиска. Самый простой случай доступ по нулевой ссылке, каждый день то тут то сям в проекте вылезает. А не должно. Или гораздо меньше. Не должно в билд просачиваться, у разработчика на машине должно уже отфильтровываться. И уже была бы польза. Экономились бы тыщи денег в виде времени, если бы не приходилось столько досадных оплошностей править. Дешевле потратить из восьми часов один на тесты чем потом исправлять (а если проблема вылезет у заказчика, там и имидж и все ведь) Достаточно огородить себя от широко распространенных ошибок. Уже будет польза.

[Alexej Simakov]

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

Answer 2

[Сергей]

Чем больше тестов, тем лучше.
Тесты не гарантируют корректность кода и идей.
Нормальный тест это "тест черной коробки" - мы не знаем как она реализуется, но мы может проверить как она реагирует на воздействия из вне.
Если мы залезли в черную коробку и копаемся внутри, то ранее написанные тесты дают некоторую гарантию, что мы ничего не поломали.

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

Comments

[Григорий Васильков]

То есть изначально ставится задача на предприятии, потом создаются куча тестов, которые учитывают условия (таким образом гарантируются рамки программы), а потом пишется функция, которая проходит этот тест, так чтоли?

[Сергей]

лучше делать маленькими шагами. простой тест, реализация. еще тест, реализация под него.
цикл занимает пару минут. реализация самым простым способом. только, что бы тесты прошли. после успешного теста рефакторинг - упрощение. повторяем это много много раз. В итоге получается довольно гибкая система. ( так как она постоянно менялась в процессе, и это потребовало гибкой архитектуры). И куча тестов. Внешне система включает только то что нужно. Так как мы исходили от тестов. Остальное скрыто.
Для примера. пишем игру Пятнадцать.
(набор костяшек с номерами. Костяшки могут двигаться лево, право, вверх, вниз если рядом пустое место)

Думаем с чего начать, что можно протестировать.
Ну допустим есть функция вернуть элемент по индексам(1,1)
пишем тест:
ТЕСТ
Создать Игру
элемент(1,1) == 1

проверяем: тест не работает по причине нет функции "элемент". тест не запускается
Создаем функцию "элемент" которая тупо возвращает 0
проверяем: тест работает по причине 0==0
Тест прошел.
Создаем новый тест: элемент 2,1 == 4
Тест не проходит 0 != 4
Тупо пишем например (i-1)* 4 + j
тест проходит.
Думаем дальше. Если костяшка рядом с 0 то они меняются. Так становится понятно что нам не нужно реализовывать некую сущность "костяшка которая двигается лево, право, вверх,... Достаточно реализовать обмен с 0. Также вопрос как сделать учет костяшек. Самое простое это массив.
Оказывается что половина инициализации уже написана. Это (i-1)*4+j. Выносим это в отдельный приват метод. Добавляем метод инициализацию массива.
Запускаем тесты. Прошло.
Далее. Пишем тест на обмен костяшек по номеру i,j с костяшкой 0.
move(2,1)
test element(1,1) == 4
test element(2,1) == 0
тест не проходит. нет функции. Пишем функцию.
тест не проходит. реализуем функцию. как обмен элементов в массиве с 0.
тест не проходит. Немного думаем. оказывается забыли поменять функцию элемент. она должна возвращать уже элемент массива.
тест проходит.
Пишем новый тест.
move(3,3)
test element(3,3)==10
тест не проходит 0!=10. костяшка в середине передвинулась хотя не должна была.
лезем в метод муве и делаем запрет на обмен местами если 0 не рядом.
запускаем тест. проходит. Нормально.
....

и т.д.
....
в итоге мы получили простую реализацию. объекта игра.мы не создали новую сущность "костяшка". которую могли создать если бы делали это при раннем проектировании.
Этот пример конечно, тривиален, но примерно так.
В интернете есть классное видео пример
https://youtu.be/lDdJYid8NpE
посмотри.

[Сергей]

Григорий Васильков: материала по теме много

[Григорий Васильков]

Вот теперь совершенно все понял! Нижайше благодарствую

Answer 3

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

Comments

[Григорий Васильков]

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

Вы вроде объяснили что и как с большего, с другой стороны сразу же обосрали, приопустили, указали на недостатки личности. Как бы и спасибо и пошел нахуй одновременно. Ну и я так же отвечу. Спасибо. Пошел на хуй :)

[Tyranron]

Григорий Васильков: Пожалуйста =) Немного прямоты ещё никому не мешало =)
Рад, что мой ответ действительно оказался Вам полезен.

[Григорий Васильков]

Ладно если серьезно - то полезно, хоть все на свои места стало.

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

Слишком много раз мне удавалось, с помощью недоверия объяснить то, что происходит вокруг, а позитивная картина мира не находила ответов. Хорошо ли мне в этом жить? Не думаю. Но знаю, что положи на войне оружие, прилетит из-за первого же угла. Опять.