Зачем тестировать код?

Question

[dev400]

Вот пишу я к примеру простой код.
Нужно мне реализовать сохранение новостей в базе.

Захожу в phpmyadmin, посмотреть структуру таблицы.


ага, структура колонок и их названия мы знаем.

Готовлю представление

и тд...
пусть оно будет таким для быстроты вникания.

В контроллере валидируем данные, если они пришли, то вызываем модель

public function insertPages(Array $array) {


        $params = [
            "title" => $array['title'],
            "url" => $array['url'],
            "content" => $array['content'],
            "keywords" => $array['keywords'],
            "description" => $array['description'],

        ];

        $sql = "INSERT INTO {$this->table} (`title`,`url`, `content`, `keywords`, `description`) VALUES (:title, :url, :content, :keywords, :description)";

        if( !parent::save( $params, $sql ) ) {

            throw new \Exception('Ошибка добавления статьи');

        }

    }

Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.

Answer 1

[Сергей Протько]

Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.

вы должны проверять корректность работы системы. Всего-то. Причем с оглядкой не только на "сейчас" (тут мы и руками можем проверить быстро) но еще с оглядкой на будущее. Если вы планируете этот код выкинуть - тестировать его нет смысла. Вы на автоматизацию тестирования убьете больше времени чем проверите руками.

С другой стороны, если это лишь вершина айсберга, то имеет смысл написать простенький автотестик, который проверяет корректность работы. Так, если мы будем вносить какие-то изменения, например будем добавлять комменты, мы будем уверены на 90% что ничего не сломали. Почему не на 100%? потому что невозможно покрыть все тестовые сценарии да и это не выгодно. Проверяем мы обычно самые вероятные сценарии.

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

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

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

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

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

Comments

[Иван Антонов]

Вам нужно в преподаватели идти. Чётко и по делу. :)

Answer 2

[xmoonlight]

Здесь нужно тестировать два важных момента:
1. Насколько корректно работает валидация данных в контроллере? (кода валидации здесь не преведено)
2. Насколько стабильно отрабатывается непосредственно добавление материалов в БД при параллельных запросах, высокой нагрузке и одинаковых материалах? (проверка стабильности соединения с БД под нагрузкой и проверка отсутствия ложных срабатываний исключений, а при их наличии - корректная дальнейшая обработка)

Comments

[dev400]

Валидация lite - ампутация пробелов в начале и конце, проверка пустоты полей.

[xmoonlight]

Андрей: валидация данных всегда должна идти "белым" списком (по принципу firewall'a). "Запрещено всё, кроме ..." и "размер данных (длина строки) должен быть в диапазоне от ... и до..."
Для текста: всё это делается после приведения к нужной кодировке, вырезанию лишних символов, тримминга, замены разнородных пробелов/тире к однотипным (если необходимо) и удалению подряд идущих пробелов.
Т.е. все данные, перед помещением в БД, должны соответствовать ОЖИДАЕМЫМ ДАННЫМ этой БД.

[dev400]

xmoonlight: а как протестировать работу при параллельных запросах? Самому это имитировать не получится))

[xmoonlight]

Андрей: см. ab (apache benchmark)

Answer 3

[VekaVeka]

Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.

Никто не говорил что прямо здесь тестировать обязательно.

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

Если у тебя мелкий софт - тесты можно и не писать.

Если у тебя софт среднего размера - ты запросто что то сломаешь незаметно для себя самого.

Comments

[dev400]

ну в независимости от размера кода я хочу развиваться

[VekaVeka]

Андрей: все подряд с тестам делать - задолбаешься.
почитай что нужно тестить, а что нет - это мнение автора известных программ Vagrant и Consul https://speakerdeck.com/mitchellh/advanced-testing...
Язык не важен. То что относится конкретно к языку - пропускай.
А общие рассуждения - очень даже интересны.

Вот здесь по русски обсуждают эти идеи и комментируют что по их мнению нужно тестировать, а что нет.
devzen.ru/episode-0095

Answer 4

[Rou1997]

Как что? Проверяйте, не выбрасывается ли исключение!

Comments

[dev400]

для этого использовать phpunit?

[Rou1997]

Андрей: Это уже вам решать, бывает просто функциональное тестирование, "зашел - посмотрел - потыкал - работает", тоже тестирование.

[dev400]

Rou1997: это само собой понятно

Answer 5

[Данил Бирюков-Романов]

Не тестируйте, если этого не надо.

Answer 6

[Igor Kalashnikov]

Отдельный вопрос действительно ли нужны вам тесты.

Но если очень хочется, то можно, например, тестировать, что после вызова insertPages у вас действительно вставилась страница.
Для этого мокаете базу, выполняете инсерт, потом получаете эту запись из базы, сравниваете, проверяя совпадает ли то что вы записывали и то что записалось.
Зачем? Ну например, завтра какой-нибудь "Вася" на проекте поменяет поле "content" в базе на "content_id" и нормально не отрефакторит код.

Так же можно проверить, что будет с невалидными данными, они должны выбросить исключение, ну и т.п.