Владимир Хориков 'Effective Unit Testing'

В этом докладе мы поговорим про принципы эффективного юнит тестирования. В частности:
- Что из себя представляет хороший юнит тест -- параметры, по которым нужно оценивать тесты
- Почему невозможно написать тест, идеальный по всем параметрам, и на какие компромиссы приходится идти при написании тестов
- Основные ошибки при использовании моков, в частности почему не нужно мочить базу данных
- Паттерн Humble Object и его применение для изоляции бизнес логики от внешнего мира для упрощения тестирования

[IvanenkoStepan]

Уже почти прочитал книгу автора.
Он один из немногих, у кого есть талант учить

[arakovskiy]

Эх, Владимир! Надо иначе называть доклады. Наткнулся несколько месяцев назад и скипнул, думая, что ничего нового для меня тут нет. Впоследствии сам наткнулся на обсуждение проблем test implementation coupling и понял, что это ошибка, которую я сам все это время делал, и в этом видео она как раз разбирается.

[Dimestel]

Хотелось бы доклад и про интеграционное тестирование. Спасибо

[abaitoguzbayev]

02:00 Как измерить эффективность юнит-тестов?
07:06 Пример: ложные срабатывания
12:09 Связь между первыми двумя параметрами
16:45 Связь между первыми тремя параметрами (функц., тривиальные, хрупкие тесты)
21:45 Вопросы по 1 части
29:00 Как писать эффективные тесты
36:46 Паттерн Humble Object (разделение переусложненного кода)
40:20 Тест-пирамида
41:47 Вопросы по 2 части
52:18 Когда нужно использовать моки?
1:00:12 Вопросы по 3 части

[MagicRemarque]

Прошу прощения, если ответ был дан в видео (ещё не до конца посмотрел). Какие книги можете посоветовать для изучения основ unit тестирования? Пишу на шарпе, net core

[OStrekalovsky]

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

[OStrekalovsky]

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

[OStrekalovsky]

У автора каша в голове - рефакторинг это изменение структуры, а не внешнего поведения. Изменение SQL запроса из его примера - это изменение внешнего поведения, пусть он может иногда и возвращать один и тот же результат. Select * и select UserID, Name, Email - это не одинаковые запросы.