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

[@IvanenkoStepan]

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

[@abaitoguzbayev5736]

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 части

[@arakovskiy]

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

[@Dimestel]

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

[@MagicRemarque]

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

[@AlexeiVinogradovIT]

www.manning.com/books/unit-testing - вот эту в любом случае! :-)

[@gijduvon6379]

art of unit testing - классика

[@OStrekalovsky]

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

[@OStrekalovsky]

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

[@gijduvon6379]

Чо самый умный что ли? Иди отсюда

[@OStrekalovsky]

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