kn0ckn0ck

Функциональные тесты относятся к системе в целом и проверяют выполнение бизнес-функций системы. Система обычно состоит из нескольких модулей. Модульные тесты применяются к модулям. Также модульность - многоплановое понятие. Может быть модуль (unit) "класс", а может быть модуль "сервис". Главное то, что модуль - это техническое понятие (пользователю все равно как вы там внутри на модули все разложили), а функции системы всегда имеют бизнес смысл.

Актуальность этой специализации только растет. Очень рекомендую это направление. Работу можно найти в крупных компаниях (с прогрессивным подходом в разработке). Работу можно найти за рубежом.

Обычно, для ведения документации и хранения тестовых отчетов тестировщики пользуются чем-то вроде этого: TestRail, Devprom ALM, TestLink, qTest и далее по списку Test Case Management systems

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

Перед выполнением каждого теста должны быть обеспечены соответствующие предусловия и не придется делать прямых запросов к БД.

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

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

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

То есть правильно было бы сформулировать вопрос таким образом: "какой процент покрытия модульными тестами будет достаточным для моего кода?" Обычно останавливаются где-то на 70-80%

Также очевидно, что 100% работающих модульных тестов не гарантирует работу интеграционных тестов или функциональных. Поэтому необходимо писать и те и другие.

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

Конечно автору курса двойку за объяснение, он его так и не дал :) Другое дело, что скорее всего здесь имелось ввиду форма документирования проверки. Чек-лист - это простая форма проверки: тут есть, там есть, тут нормально, там тоже ничего. Тест-кейсы обычно куда более сложные, объемные и разноплановые, поскольку многие проверки не укладываются в простановку галочек.