Как писать тесты?

Question

[Оптимус Пьян]

Понятно только как писать тесты к функциям которые что-то валидируют и отвечают true или false
Возьмём классическую регистрацию сайта:
1) Непосредственно регистрация с занесением в БД
2) Верификация email с update в БД поля verification
3) Восстановление забытого пароля на почту (напрямую или с помощью ссылки)
4) Поиск допустим какой ни будь в интернет-магазине по свойствам товара

Как написать тест для чего-то что работает с БД, не говоря уж о тестах вещей которые работают с API?
Верификация email - PHPmailer для отправки сработал, дальше мы не можем ничего протестировать, на этом конец?
Восстановление пароля можно протестировать только если в БД есть хеш который можно по ссылке найти и восстановить пароль. Выходит что тест должен сам для себя предварительно создать хеш в БД, потом обновить пароль, но вход протестировать он всё равно не сможет? У тестов тогда очень сильная завязка на БД получается и при изменении её архитектуры всё надо переписывать?

Comments

[dom1n1k]

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

[lukoie]

теги к вопросу добавьте, как минимум "QA"

Answer 1

[nonlux]

Ну тесты бываю разными: и зелеными и красными. ))

Все зависит от уровня абстракции, который хочется протестировать. Поэтому тесты и делятся на всяческие классификации. Например: юнит (модульные) тесты, интеграционные тесты и т.д. и т.п.

Я как ярый сторонник BDD использую два типа тестов feature (читай интеграционные тесты) и spec (читай юнит тесты)

Итак, features. Берем Behat и херачем кучу тестов по типу:
Зашел на главную,
Потыкал чего-то в форме регистрации
Зашел в профиль и увидел свое имя и фотку на странице
Profit!

Вот в целом и получили: "Непосредственно регистрация с занесением в БД", только в этой ситуации нам абсолютно не важно что там в БД. Нам важно чтобы пользователь зарегистрировался и попал в закрытый раздел сайта.

Для таких тестов хорошо иметь поддержку окружения (prodaction, development, test) в коде, чтобы например можно было капчу отключить или еще какую сложную лабуду не делать.
Если система замудрена до ужаса придется здесь для тестов все окружение поднимать. А лучще вообще отдать CI такое делать пусть друг трудится.
Плюс таких тестов например когда пишем сложный фронт - сложный бек и еще более сложнейший бек-бек, то можно одним чохом протестировать работу всего сервиса.

Следующий уровень абстракции spec:

Если нам в интеграционных тестах было немного пофиг на БД. Она как бы пишет, но что так за структура абсолютно пофиг. То в случае со спекими нам ВАЩЕ ПОФИГ.
Мы берем наш класс (функцию) и проверяем что за результаты она отдает. Вместо объектов, с которыми подопытный (объект тестируемого класса), даем ему резиновую бабу (моки и т.п), и смотрим на результаты нашего труда.

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

Вот как то так!

P.S тесты надо бы писать до кода.

Comments

[Оптимус Пьян]

Про тесты до кода планировал следующий вопрос задать, как их писать до если:
1) Я не знаю какая структура БД будет даже тестовая БД если
2) Я ещё не знаю что пользователь увидит в интерфейсе
Вот как вы мислите? Садитесь... итак, сейчас я напишу тест. Кода у меня пока нет и...

[xfg]

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

Answer 2

[xfg]

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

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

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

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

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

Comments

[Оптимус Пьян]

Можно пояснить что такое "мокают методы"

[xfg]

Оптимус Пьян: мок-объект - это фальшивый объект, который имитирует поведение реального объекта. Мокать методы, это значит, создать мок-объект с нужным набором методов для теста, методам можно сказать, чтобы они возвращали заранее заготовленные значения и прочее.

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

Подробнее тут https://en.wikipedia.org/wiki/Mock_object если с англ проблемы, то есть тут https://ru.wikipedia.org/wiki/Mock-объект но очень скудно.

Как этим всем пользоваться в phpunit здесь https://phpunit.de/manual/current/en/test-doubles.html

Answer 3

[Александр Новиков]

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

Ну а с остальными случаями возможны разные варианты решения. Кого-то устроит просто true, которое вернули из PHPmailer::send(), но можно и получать по POP3 новые письма с ящика, на который отправляли, и ждать прихода нужного, с отвалом с непройденным тестом по таймауту. Зависит от вашего конкретного случая

Ну и разумеется у тестов проекта (не отдельной библиотеки, которая с данными не работает) будет сильная завязка на структуре бд, и при сильном изменении ее структуры/кода связанного с ней тесты упадут, и нужно будет их переписать, ровно как и связанный с ними код, для того они и нужны )

Answer 4

[Дмитрий]

Тесты для кого? Для человека или для машины?
Я к тому, что тесты бывают разными: ручные и автоматические. Про это ничего не сказано в вашем вопросе!

Какие именно тесты нужны? Модульные? Интеграционные? Инсталяции? Нагрузочные? Про это тоже ни слова в вашем вопросе!

Тесты пишут так:
1. Выявляют сначала рабочие сценарии, т.е. когда все хорошо и появляется результат. Есть огромное кол-во ситуаций, когда пользователь готов заплатить забажный продукт, если он хотя 1 раз и 50 запусков сделает ему то, чтобы он делал 3 дня! Сценарии сортируются по:
1.1. компонентам
1.2. приоритету и важности.

После сортировки создают наборы тестов

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

3. Только после этого проверяют "ошибку на дурака". Примеры: вместо текстового файла дали exe-файл. Или вместо числа ввели строку.

Предположу, что вы хотите писать модульные тесты. Скажу следующее что эти типы тестов не должны делать:
1. Проверять работу с БД, диском, сетью
2. Код зависящий от времени

Основной показатель модульного теста это скорость работы. Если тест такого типа работает пол-секунды, то значит вы написали что угодно, но это не модульный тест ;)

Comments

[Оптимус Пьян]

> ручные и автоматические
Автоматические для PHPUnit

> Какие именно тесты нужны? Модульные? Интеграционные? Инсталяции? Нагрузочные?
Я не разбираюсь в этом так глубоко пока

> сеть упала, флешка перстала видеться
Я для сайтостроения интересовался, там такого нет

> Если тест такого типа работает пол-секунды, то значит вы написали что угодно, но это не модульный тест
Не понял фразу, сколько же времени он должен работать и почему