Не вижу особых проблем с реализацией подобных тестовых сценариев. Может конечно у вас какой-то неожиданно особый environment, без примеров кода сложно судить.
Не видел еще ни одного проекта, где к примеру модульные тесты занимали бы хоть сколько-нибудь значительное время. Около 3000 модульных тестов в проекте бэкенда, написанного на C# с использованием ASP.NET занимало несколько секунд.
Меньше всего мне хочется спорить с кем бы то ни было о вкусах. У меня вообще нет такой цели: "За меньшее время написать тесты, имеющие наибольшее покрытие" потому что я всегда сначала пишу тест, а потом код. Я сначала пишу тесты потому что это:
Улучшает внутренний дизайн и архитектуру программной системы
Удешевляет и упрощает последующее изменение кода
Порождает "исполняемую" документацию по коду, которая никогда не врет
Упрощает повторное использование кода
Снижает стоимость эксплуатации программной системы
Юнит тесты тестируют именно поведение классов. Модули, состоящие из множества классов тестируют интеграционными тестами.
Классический подход прост. Сначала пишем тест, потом пишем код, поведение которого проверяется в тесте. Ну а поведенческий код в объектно-ориентированной парадигме обычно упаковывается в класс. Поэтому юнит тесты обычно тестируют методы одного класса.
У меня есть такой опыт. И он свидетельствует о том, что чтобы людей, годами программирующих традиционно, перевести на рельсы XP, требуются недюжинные усилия и вагон времени.
Люди — это устройства с несовместимыми интерфейсами, а парное программирование требует очень хороших коммуникационных навыков, которые как правило отсутствуют у программистов, годами работающих в одиночку.
К тому же ни один из известных мне руководителей или собственников софтверных компаний не готов нести затраты на внедрение практик, перспективных в долгосрочной перспективе, особенно на фоне того, что старый подход "каждый новый проект, как первый", приносит неплохой доход.
Я пробовал добавить в резюме в качестве требований к вакансии комплект практик гибкой разработки. Полторы тысячи просмотров работодателями, около сотни собеседований, результат нулевой. Даже TDD в классическом смысле никто из пригласивших меня на интервью не практикует, не говоря уже о парном программировании. Я сделал вывод что компаний, практикующих XP, у нас нет.
Спасибо за подробное описание, однако я ориентировался на исходный смысл латинского термина культура (возделывание, воспитание, развитие). И именно в его контексте интересно было бы понять почему вы отказались от той или иной практики.
В случаях, когда исходно "уровень качества просто не требуется" и повторное использование кодовой базы в принципе не подразумевается, я полагаю о культуре можно и не заморачиваться вовсе.
Да, я пожалуй что уверен что все, что предполагает экстремальное программирование (Agile), нужно практиковать одновременно, потому что все это как нельзя лучше соответствует семантике слова культура.
А вы как считаете? Что бы вы лично выкинули? И если вас не затруднит, то почему?
Практики, нацеленные на создание производственной культуры, позволяющей создавать программные продукты в понятные сроки и с гарантированным качеством мне кажется давно описаны старожилами отрасли, такими как Кент Бек, Роберт Мартин, Мартин Фаулер и другими.
Если команда проникнется Agile манифестом и начнет ориентироваться на повторное использование кода, будет всегда сначала писать тесты и настроит автоматическую непрерывную интеграцию и поставку, то рано или поздно будет команде счастье и культура. Вопрос только надо ли это все собственнику софтверной компании, которой принадлежит эта команда?
В общем за 20 лет работы в отрасли я ни разу не встретил команду, которая бы все это практиковала. В такой команде я бы был готов поработать не то что волонтером, но даже доплатил бы за такую возможность.
Просто "эффективный менеджмент" сейчас очень модная, трендовая тема. Многие поверили что скрам-канбан и стендапы-ретро способны мгновенно и в разы увеличить производительность работников умственного труда. Через некоторое время это пройдет… все проходит...
Обалдеть! Вы все еще здесь саблями машете!? Давайте хотя бы не на словах воевать, а код писать? Возможно в момент, когда кодовая база у нас перерастет порог в 10 тысяч строк, мы приблизимся к просветлению.
А мне теперь только такой способ мышления и кажется естественным. У меня пару раз были ситуации, когда просили за вполне неплохие деньги писать сначала код, а потом возможно тесты. Я не смог. Примерно на третий день начинается ломка, а к концу недели ступор. Больше я на такое не подписываюсь.
Парное программирование это очень прикольно. У меня уже три года не было парного программирования. :-)
На мой взгляд создатели Agile-манифеста вполне исчерпывающе высказались на эту, и похожие темы.
Не вижу особых проблем с реализацией подобных тестовых сценариев. Может конечно у вас какой-то неожиданно особый environment, без примеров кода сложно судить.
Не видел еще ни одного проекта, где к примеру модульные тесты занимали бы хоть сколько-нибудь значительное время. Около 3000 модульных тестов в проекте бэкенда, написанного на C# с использованием ASP.NET занимало несколько секунд.
А в чем проблема то с тестированием "асинхронщины"?
Главная задача для меня — получать удовольствие от программирования.
Что означает "начинаю проектировать на каком-то достаточно высоком уровне"?
Ответы на ваши вопросы есть в книгах Роберта Мартина, Кента Бека и "банды четерех" (Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес).
Меньше всего мне хочется спорить с кем бы то ни было о вкусах. У меня вообще нет такой цели: "За меньшее время написать тесты, имеющие наибольшее покрытие" потому что я всегда сначала пишу тест, а потом код. Я сначала пишу тесты потому что это:
ActiveRecord на мой взгляд — антишаблон. Модель данных не должна зависеть от механизмов хранения.
Юнит тесты тестируют именно поведение классов. Модули, состоящие из множества классов тестируют интеграционными тестами.
Классический подход прост. Сначала пишем тест, потом пишем код, поведение которого проверяется в тесте. Ну а поведенческий код в объектно-ориентированной парадигме обычно упаковывается в класс. Поэтому юнит тесты обычно тестируют методы одного класса.
Сервак, базейка, таски, фиксятся… я вдруг начал беспокоиться за свои счета в Альфа-Банке… Или это у меня признаки паранойи все ж? А?
У меня есть такой опыт. И он свидетельствует о том, что чтобы людей, годами программирующих традиционно, перевести на рельсы XP, требуются недюжинные усилия и вагон времени.
Люди — это устройства с несовместимыми интерфейсами, а парное программирование требует очень хороших коммуникационных навыков, которые как правило отсутствуют у программистов, годами работающих в одиночку.
К тому же ни один из известных мне руководителей или собственников софтверных компаний не готов нести затраты на внедрение практик, перспективных в долгосрочной перспективе, особенно на фоне того, что старый подход "каждый новый проект, как первый", приносит неплохой доход.
Не вопрос, могу перефразировать свой вывод — компаний, практикующих XP значительно-значительно меньше, нежели компаний XP не практикующих.
Я пробовал добавить в резюме в качестве требований к вакансии комплект практик гибкой разработки. Полторы тысячи просмотров работодателями, около сотни собеседований, результат нулевой. Даже TDD в классическом смысле никто из пригласивших меня на интервью не практикует, не говоря уже о парном программировании. Я сделал вывод что компаний, практикующих XP, у нас нет.
Спасибо за подробное описание, однако я ориентировался на исходный смысл латинского термина культура (возделывание, воспитание, развитие). И именно в его контексте интересно было бы понять почему вы отказались от той или иной практики.
В случаях, когда исходно "уровень качества просто не требуется" и повторное использование кодовой базы в принципе не подразумевается, я полагаю о культуре можно и не заморачиваться вовсе.
Да, я пожалуй что уверен что все, что предполагает экстремальное программирование (Agile), нужно практиковать одновременно, потому что все это как нельзя лучше соответствует семантике слова культура.
А вы как считаете? Что бы вы лично выкинули? И если вас не затруднит, то почему?
Практики, нацеленные на создание производственной культуры, позволяющей создавать программные продукты в понятные сроки и с гарантированным качеством мне кажется давно описаны старожилами отрасли, такими как Кент Бек, Роберт Мартин, Мартин Фаулер и другими.
Если команда проникнется Agile манифестом и начнет ориентироваться на повторное использование кода, будет всегда сначала писать тесты и настроит автоматическую непрерывную интеграцию и поставку, то рано или поздно будет команде счастье и культура. Вопрос только надо ли это все собственнику софтверной компании, которой принадлежит эта команда?
В общем за 20 лет работы в отрасли я ни разу не встретил команду, которая бы все это практиковала. В такой команде я бы был готов поработать не то что волонтером, но даже доплатил бы за такую возможность.
Просто "эффективный менеджмент" сейчас очень модная, трендовая тема. Многие поверили что скрам-канбан и стендапы-ретро способны мгновенно и в разы увеличить производительность работников умственного труда. Через некоторое время это пройдет… все проходит...
Обалдеть! Вы все еще здесь саблями машете!? Давайте хотя бы не на словах воевать, а код писать? Возможно в момент, когда кодовая база у нас перерастет порог в 10 тысяч строк, мы приблизимся к просветлению.
А как ваша команда оценивает какой код ты выдаешь? Каковы формальные критерии?
А мне теперь только такой способ мышления и кажется естественным. У меня пару раз были ситуации, когда просили за вполне неплохие деньги писать сначала код, а потом возможно тесты. Я не смог. Примерно на третий день начинается ломка, а к концу недели ступор. Больше я на такое не подписываюсь.
Парное программирование это очень прикольно. У меня уже три года не было парного программирования. :-)