Отвратительная мысль — свести систему поддерживающих друг друга идей и практик к одному плохо оформленному пожеланию. …Ну, и дополнить это ещё одним пожеланием, вообще не имеющим отношения к обсуждаемой теме.
Посмотрел. Но ни про "прошли те времена…", ни про универсальность там нет ничего. Лишь про то, что менеджмент подхватил идею про agile и — как это обычно бывает — утащил не туда. И про то, что программистам неплохо было бы самим заняться обустройством своей "ипархии".
В итоге получается 'given' простыня из предусловий и моков, понятная только вам, здесь и сейчас.
Вы очень наглядно показали, что в описанной ситуации надо использовать не моки, а другие виды Test Doubles.
Только такая ситуация — как вы опять же очень точно подметили — возникает не при TDD (разработке), а при тестировании.
При правильном же использовании TDD как инструмента проектирования ситуация типа
вы судорожно пытаетесь найти какие из них реально используются компонентом
исключена, так как вы этот самый компонент разрабатываете и знаете, какие именно методы репозитория вам нужны.
Если же логика работы с репозиторием в какой-то момент становится сложной — это явный повод выделить объект, который будет позволять абстрагироваться от этой сложности. Рефакторинг (в том числе и тестов!) в руки.
Впрочем, TDD как инструмент проектирования вы же отвергаете… Может, в этом и проблема?
Меня как раз учили, что тот, кто код писал, не имеет права быть его тестировщиком.
Очень правильно учили!
Ну то есть может протестировать, но должен быть еще кто-то с независимым взглядом. В случае TDD это ограничение обходится,
TDD не исключает последующего тестирования. TDD вообще к тестированию не имеет отношения — это разработка (и не обращайте внимания на устоявшийся рускоязычный перевод — он вводит в заблуждение). Разработанный через TDD код в дальнейшем должен тестироваться точно так же, как и любой другой.
Не для каждого кода нужно получить фазу red в начале. Она была нужна в 2000 году, т.к. у них не было инструментария который позволял работать иначе.
Можно про это подробнее: какого инструментария не было 2000-м году у Бека?
Если вы про это
Например сейчас я могу задекларировать в IDE функцию/метод с сигнатурой и выбросить исключение "Not Implemented", нажать комбинацию клавиш и мне сгенерируется тест сьют, нажать пару раз tab и получить тест вызывающий нереализованную функцию.
А можете уточнить, где именно в этом видео увязывается "agile-ность" с описанной вами профессиональной универсальностью? И/или где там вообще рассказывается про суть "agile-ности"?
Просто ваше утверждение выглядит — если говорить осторожно — сомнительно. Особенно в связке с переводом agile как гибкости. Но тратить два часа жизни (реально будет существенно больше) на проверку совсем не хочется.
Поиск по расшифровке дал ровно два упоминания слова "agile" в течение 10 секунд и в совершенно другом контексте.
Ну, и тут у вас все шансы победить!
Вам не кажется!
Отвратительная мысль — свести систему поддерживающих друг друга идей и практик к одному плохо оформленному пожеланию. …Ну, и дополнить это ещё одним пожеланием, вообще не имеющим отношения к обсуждаемой теме.
У вас намечается соревнование по тому, кто хуже понял смысл TDD? :)
Можно уточнить?
Вы прочитали книгу Бека "Экстремальное программирование. Разработка через тестирование", и всё, что из неё вынесли — вот этот "секрет"?
Я правильно понял?
Посмотрел. Но ни про "прошли те времена…", ни про универсальность там нет ничего. Лишь про то, что менеджмент подхватил идею про agile и — как это обычно бывает — утащил не туда. И про то, что программистам неплохо было бы самим заняться обустройством своей "ипархии".
Спасибо, посмотрю.
А как написан код, который достаёт из БД нужные данные и засовывает их в параметры?
Вы очень наглядно показали, что в описанной ситуации надо использовать не моки, а другие виды Test Doubles.
Только такая ситуация — как вы опять же очень точно подметили — возникает не при TDD (разработке), а при тестировании.
При правильном же использовании TDD как инструмента проектирования ситуация типа
исключена, так как вы этот самый компонент разрабатываете и знаете, какие именно методы репозитория вам нужны.
Если же логика работы с репозиторием в какой-то момент становится сложной — это явный повод выделить объект, который будет позволять абстрагироваться от этой сложности. Рефакторинг (в том числе и тестов!) в руки.
Впрочем, TDD как инструмент проектирования вы же отвергаете… Может, в этом и проблема?
Тесты для вас не код? Или у тестов какие-то другие стандарты внутреннего качества? Вы в тестах, например, дублирование не устраняете?
Но это только если вы заранее знаете, какая форма будет правильной.
Я правильно понимаю, что речь идёт про описанный Беком "классический" TDD? "Лондонскую школу" (BDD) никоим образом сюда не привязываем?
Очень правильно учили!
TDD не исключает последующего тестирования. TDD вообще к тестированию не имеет отношения — это разработка (и не обращайте внимания на устоявшийся рускоязычный перевод — он вводит в заблуждение). Разработанный через TDD код в дальнейшем должен тестироваться точно так же, как и любой другой.
Можно про это подробнее: какого инструментария не было 2000-м году у Бека?
Если вы про это
то ваш тезис неверен. TDD рождалось на Smalltalk-е.
А можете уточнить, где именно в этом видео увязывается "agile-ность" с описанной вами профессиональной универсальностью? И/или где там вообще рассказывается про суть "agile-ности"?
Просто ваше утверждение выглядит — если говорить осторожно — сомнительно. Особенно в связке с переводом agile как гибкости. Но тратить два часа жизни (реально будет существенно больше) на проверку совсем не хочется.
Поиск по расшифровке дал ровно два упоминания слова "agile" в течение 10 секунд и в совершенно другом контексте.
Предыдущие ответы дополню намёком: agile — это не существительное, это прилагательное.
Хотите перестать страдать? Разберитесь уже, что такое ООП. И это не "громоздкие иерархии". Это даже не про классы.
Он всего лишь неправильно понимает суть ООП. Впрочем, как и миллионы бедолаг, которым втюхивали, что ООП — это про иерархии классов.
Универсальная архитектура на все случаи жизни! Этими устами бы да мёд пить.
Да, лучше. Но только если бизнес понимает свои потребности правильно.