Комментарии
Избранное
Подписка
Сортировка:
Древо развёрнутое
Свернуть все
Поспорю с тезисом:
Никому, ни одному руководителю не нужна была эта технология именно из-за увеличения локальных сроков разработки.
Если договорится, что выполненной задача считает тогда, когда пользователь может нормально работать, то сроки разработки одинаковые. Их только считают неправильно.
А так спасибо за труд =)
+ втянутся в тестирование неочень легко, надо хотя бы пару книжек прочитать и научиться писать тестируемый код. А самому это довольно-таки тяжело.
Никому, ни одному руководителю не нужна была эта технология именно из-за увеличения локальных сроков разработки.
Если договорится, что выполненной задача считает тогда, когда пользователь может нормально работать, то сроки разработки одинаковые. Их только считают неправильно.
А так спасибо за труд =)
+ втянутся в тестирование неочень легко, надо хотя бы пару книжек прочитать и научиться писать тестируемый код. А самому это довольно-таки тяжело.
Абсолютно согласен только тогда, когда твой руководитель замыкает весь цикл разработки, а когда руководитель разработки ПО стремится быстрее отдать в отдел тестирования, то тут его мало интересует качество кода до того момента, пока ему в KPI не поставят показатель количества возвратов на доработку!
(3) А вот и уважаемый мною, artbear!
Проект объединен в единый общий репозиторий ADD
- объединенный проект содержит в себе
BDD - bddRunner
TDD - tddRunner
единые расширения для тестирования
(4)
Да уж, хоть как то сделать легче пользователям - это научиться правильному подходу самому!
Проект объединен в единый общий репозиторий ADD
- объединенный проект содержит в себе
BDD - bddRunner
TDD - tddRunner
единые расширения для тестирования
(4)
Мне понравился термин "РМП" - разработка через муки пользователя, :) помимо многих мыслей.
Да уж, хоть как то сделать легче пользователям - это научиться правильному подходу самому!
Проблема в головах трудно решаемая задача, но решаемая)
Также, на мой взгляд, существенные трудности вносит некоторая не совместимость подхода TDD с 1С, его можно относительно эффективно использовать при части решаемых задач.
Также, на мой взгляд, существенные трудности вносит некоторая не совместимость подхода TDD с 1С, его можно относительно эффективно использовать при части решаемых задач.
(7)Во-первых, если внимательно читали, то я утверждаю, что его эффективно использовать при части решаемых задач. Это значит, что деньги/время/эффективность при некоторых условиях перевешивают весы в другую сторону.
Во-вторых, расскажите мне как вы обходите отсутствие возможность создать mock объекты в 1С.
Во-вторых, расскажите мне как вы обходите отсутствие возможность создать mock объекты в 1С.
(13)
А пока никак на данной ветке своей эволюции в разработке через TDD.
Я прочитал Вашу статью и нашел много полезностей, которые еще предстоит осознать и пощупать на практике.
Но при всем при этом, тому функционалу, который мне приходилось обвязать тестами, не требовались ни подставные объекты, ни заглушки.
Я даже не представляю пока как их применить в тестировании в 1С.
Есть статьи на эту тему или достойная книга на Ваш взгляд?
mock объекты в 1С
А пока никак на данной ветке своей эволюции в разработке через TDD.
Я прочитал Вашу статью и нашел много полезностей, которые еще предстоит осознать и пощупать на практике.
Но при всем при этом, тому функционалу, который мне приходилось обвязать тестами, не требовались ни подставные объекты, ни заглушки.
Я даже не представляю пока как их применить в тестировании в 1С.
Есть статьи на эту тему или достойная книга на Ваш взгляд?
(14)
1. В некотором приближении макет можно назвать мок объектом.
2. В рамках TDD и 1С я видел только статьи от Артура Аюханова и Ко.
3. По-моему опыту, эффективно обвязывать тестом блоки функций (относительно большой кусок). Обвязывать маленькую функцию слишком времязатратно и не эффективно (время/деньги/качество/люди).
4. Читать другие книги по TDD тяжело, т.к. проекция примеров в 1С нельзя спроецировать один в один (Книга «Экстремальное программирование: разработка через тестирование»).
5. У нас в компании, я в ближайшее время планирую провести вебинар посвященный тестированию юнит и TDD, думаю, я выложу на youtube канале некоторую интерпретацию некоторое время после.
1. В некотором приближении макет можно назвать мок объектом.
2. В рамках TDD и 1С я видел только статьи от Артура Аюханова и Ко.
3. По-моему опыту, эффективно обвязывать тестом блоки функций (относительно большой кусок). Обвязывать маленькую функцию слишком времязатратно и не эффективно (время/деньги/качество/люди).
4. Читать другие книги по TDD тяжело, т.к. проекция примеров в 1С нельзя спроецировать один в один (Книга «Экстремальное программирование: разработка через тестирование»).
5. У нас в компании, я в ближайшее время планирую провести вебинар посвященный тестированию юнит и TDD, думаю, я выложу на youtube канале некоторую интерпретацию некоторое время после.
(20)
А по-моему наоборот. Легко получается писать unit-тесты, если функция маленькая и имеет мало зависимостей. Например, очень просто написать тест на функцию, чьими параметрами будет выступать пара документов и элементов справочников. Тогда и макеты не нужны. Можно создать пару элементов справочника только с нужными зависимостями.
К примеру, документ реализация, 2 номенклатуры и один склад. И мы уже можем протестировать движения документа по складскому контуру.
Т.е. в качестве границ выступают не интерфейсы (к примеру), а метаданные. И чем к меньшему кол-ву метаданных мы сведем, тем более тестируемый и простой получится код.
Если писать unit-тесты сразу, то получается не так трудозатратно и выигрыш больше. Но большинство существующего кода 1с тестируется плохо, с вами согласен. Зависимость от БД слишком велика.
А по-моему наоборот. Легко получается писать unit-тесты, если функция маленькая и имеет мало зависимостей. Например, очень просто написать тест на функцию, чьими параметрами будет выступать пара документов и элементов справочников. Тогда и макеты не нужны. Можно создать пару элементов справочника только с нужными зависимостями.
К примеру, документ реализация, 2 номенклатуры и один склад. И мы уже можем протестировать движения документа по складскому контуру.
Т.е. в качестве границ выступают не интерфейсы (к примеру), а метаданные. И чем к меньшему кол-ву метаданных мы сведем, тем более тестируемый и простой получится код.
Если писать unit-тесты сразу, то получается не так трудозатратно и выигрыш больше. Но большинство существующего кода 1с тестируется плохо, с вами согласен. Зависимость от БД слишком велика.
(20)
Насчет моков. У нас тоже достаточно большое поле возможностей и фантазии.
1. Тесты, обычно, обрамляются началом/откатом транзакции. Можно создать свой тестовый документ/справочник, записать и использовать его ссылку. При откате транзакции - будто ничего и не было.
2. Примерно тоже, что и п.1, только объект можно заполнить какими-то предварительно сериализованными данными.
3. Как иногда в типовых, подменять Структурой.
Насчет моков. У нас тоже достаточно большое поле возможностей и фантазии.
1. Тесты, обычно, обрамляются началом/откатом транзакции. Можно создать свой тестовый документ/справочник, записать и использовать его ссылку. При откате транзакции - будто ничего и не было.
2. Примерно тоже, что и п.1, только объект можно заполнить какими-то предварительно сериализованными данными.
3. Как иногда в типовых, подменять Структурой.
(20) Насчет
Ну не знаю... Как по мне, эта книжка достаточно правильно заряжает. И главное, вдалбливает режим "красный-зеленый-рефакторинг". Даже если этого не соблюдаешь, то как-то всегда помнится об этом.
4. Читать другие книги по TDD тяжело, т.к. проекция примеров в 1С нельзя спроецировать один в один (Книга «Экстремальное программирование: разработка через тестирование»).
Ну не знаю... Как по мне, эта книжка достаточно правильно заряжает. И главное, вдалбливает режим "красный-зеленый-рефакторинг". Даже если этого не соблюдаешь, то как-то всегда помнится об этом.
Хорошая статья. Знакомо до боли.
Но я так и не понял, чем всё закончилось? Автор, где сейчас работаешь? Всё также подпольно пишешь и запускаешь тесты? Или уже заразил всю команду зелеными кружочками?
Но я так и не понял, чем всё закончилось? Автор, где сейчас работаешь? Всё также подпольно пишешь и запускаешь тесты? Или уже заразил всю команду зелеными кружочками?
(10) Дымовые тесты же всем показывал?
Вообще, когда/если ты уйдешь с текущей работы, к тебе будут обращаться с вопросами про вю эту магию.
Сейчас даже немножко попроще - и материалов полно (платных и бесплатных), и инструменты заметно подтянулись + вышли новые.
Но всем надо "здесь и сейчас", а играть "вдлинную" никто не хочет или не умеет.
Вообще, когда/если ты уйдешь с текущей работы, к тебе будут обращаться с вопросами про вю эту магию.
Сейчас даже немножко попроще - и материалов полно (платных и бесплатных), и инструменты заметно подтянулись + вышли новые.
Но всем надо "здесь и сейчас", а играть "вдлинную" никто не хочет или не умеет.
Да меня после зеленых кружочков никто не понял, почему сроки по новой подсистеме неоправданно высокие!
А если бы про "дымовые" заикнулся - все бы расценили как попытку поджёга офиса;-)
(11)
Так и есть, заниматься можно постоянно повышая свой профессиональный уровень.
(11)
Причины, на мой взгляд, очевидны, я их описал в публикации и изменить парадигму в коллективе сможет только тот, кто будет заточен на качество с большой буквы К.
А если бы про "дымовые" заикнулся - все бы расценили как попытку поджёга офиса;-)
(11)
Сейчас даже немножко попроще - и материалов полно (платных и бесплатных), и инструменты заметно подтянулись + вышли новые.
Так и есть, заниматься можно постоянно повышая свой профессиональный уровень.
(11)
Но всем надо "здесь и сейчас", а играть "вдлинную" никто не хочет или не умеет.
Причины, на мой взгляд, очевидны, я их описал в публикации и изменить парадигму в коллективе сможет только тот, кто будет заточен на качество с большой буквы К.
(11)
Или забросят, если никому не интересно, то продолжать не будут. Пробовал внедрять "промышленные подходы" после аналогичного курса. Всё из под палки, потом и самому всё это надоело.
Вообще, когда/если ты уйдешь с текущей работы, к тебе будут обращаться с вопросами про вю эту магию.
Или забросят, если никому не интересно, то продолжать не будут. Пробовал внедрять "промышленные подходы" после аналогичного курса. Всё из под палки, потом и самому всё это надоело.
Если будет больше статей практического характера, то и не будет, постоянного, простите, нытья, о том, что тестирование - круто, но большинство настолько слабы душой, что не тянут. Нет, ну серьёзно, если есть желание двигать тему - нужны тематические материалы, а не рассказы: "никто не использует тестирование, а ведь это так круто, ведь я попробовал и у же получается".
(15) Абсолютно верно, только учить нужно тем, кто в этом гуру, а тем кто начинает путь, если есть желание, рассказывать каков он, этот путь.
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания!
Иначе, можно так научить, что переучивать дороже станет.
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания!
Иначе, можно так научить, что переучивать дороже станет.
(16) Ждем следующей статьи, не нужно обучающей, просто поделитесь практическим примером наработок, к чему пришли, какие сложности и т.д. с точностью до строки кода. Понимаете, тема тестирования уже сильно взбудоражена и до нас вами, и не очень большое количество статей, где об этом рассказывается на практических примерах, начинает раздражать большую гвардию программистов, которые пытаются и не получается (не у всех хватает выдержки, но и ведь она не обязательно должна у них быть!)
(16)
Учить и делиться практическим опытом - разные вещи. Ждать гуру для этого не стоит, можно не дождаться )) "Нет взрослых, кроме нас самих". Что мы публикуем и чем делимся друг с другом, то и становится фундаментом для нашего развития. Все использованные Вами инструменты относятся к миру Freeware и Open Source. А в нём всё именно так и работает.
У Вас наверняка были какие-то конкретные сложности при настройке инструментов. Вы их как-то обходили. Выполняли конкретные действия. Наверняка есть подборка источников информации. Их можно сгруппировать по тематикам. Привести пример своего, пускай и небольшого, теста. Снять скриншоты. И сделать публикацию на Инфостарте. Которую затем можно будет сколько угодно редактировать и дополнять по результатам обсуждения в комментариях.
Не хватает практических примеров? Да, есть такое. Многие публикации действительно пишутся на недосягаемом уровне абстракции и не содержит последовательности шагов от начала до конца для достижения цели. Так значит ниша ещё пуста! Заполняйте её.
Это позволило бы добиться сразу нескольких целей:
1) Повысить интерес к теме и её популярность. Это было бы гораздо лучше демотивации от утверждений о ненужности тестирования руководству. То, что 1С вместе со многими руководителями растут с низовых слоев бизнеса, где и планирование и качество не в чести, итак известно. Но ситуация улучшается, во многом благодаря сообществу и авторам, которые развивают эту тему.
2) Дать понять другим авторам, куда лучше копать, когда они будут делать публикации на эту тему. Может быть это поможет контрибьюторам проекта улучшить справку по инструментам. Между прочим в обработке bddRunner сейчас есть довольно хорошая встроенная справка.
3) Сами же лучше систематизируете и структурируете для себя информацию. Под чем-то подведете черту. Где-то увидите новые пути для самого себя.
Вообще, если в публикации правильно употребляются понятия TDD/BDD и не путаются с "покрытием тестами", то попытка сходу начать применять TDD/BDD кажется рискованной. Может быть лучше сначала начать с покрытия тестами?
Это не обязательно должен быть тот функционал, который от Вас требуют прямо сегодня-завтра. Покрывать тестами можно уже реализованный и отлаженный функционал, который по разумным соображениям кажется наиболее критичным для работы системы. Или тот функционал, который по статистике чаще всего выходит из строя в результате изменения системы. Затем можно перейти к подходу "нашел баг -> исправил -> покрыл тестом". Покрытие тестом можно сделать прямо по сценарию воспроизведения бага.
Может быть стоит оставить экстремальный подход работы через TDD/BDD на время, когда Вы сами сможете определять подходы к разработке? Если начать с постепенного покрытия тестами, то Вы и свои технические навыки применения инструментов повысите и система станет стабильнее. Реализацию же новых задач пока оставить как есть, покрывая их тестами, когда появится такая возможность.
BDD - это же вообще об общении постановщика задач (заказчика) с разработчиком. Покрытие тестами и сценарное тестирование - чуть другое :
учить нужно тем, кто в этом гуру
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания
Учить и делиться практическим опытом - разные вещи. Ждать гуру для этого не стоит, можно не дождаться )) "Нет взрослых, кроме нас самих". Что мы публикуем и чем делимся друг с другом, то и становится фундаментом для нашего развития. Все использованные Вами инструменты относятся к миру Freeware и Open Source. А в нём всё именно так и работает.
У Вас наверняка были какие-то конкретные сложности при настройке инструментов. Вы их как-то обходили. Выполняли конкретные действия. Наверняка есть подборка источников информации. Их можно сгруппировать по тематикам. Привести пример своего, пускай и небольшого, теста. Снять скриншоты. И сделать публикацию на Инфостарте. Которую затем можно будет сколько угодно редактировать и дополнять по результатам обсуждения в комментариях.
Не хватает практических примеров? Да, есть такое. Многие публикации действительно пишутся на недосягаемом уровне абстракции и не содержит последовательности шагов от начала до конца для достижения цели. Так значит ниша ещё пуста! Заполняйте её.
Это позволило бы добиться сразу нескольких целей:
1) Повысить интерес к теме и её популярность. Это было бы гораздо лучше демотивации от утверждений о ненужности тестирования руководству. То, что 1С вместе со многими руководителями растут с низовых слоев бизнеса, где и планирование и качество не в чести, итак известно. Но ситуация улучшается, во многом благодаря сообществу и авторам, которые развивают эту тему.
2) Дать понять другим авторам, куда лучше копать, когда они будут делать публикации на эту тему. Может быть это поможет контрибьюторам проекта улучшить справку по инструментам. Между прочим в обработке bddRunner сейчас есть довольно хорошая встроенная справка.
3) Сами же лучше систематизируете и структурируете для себя информацию. Под чем-то подведете черту. Где-то увидите новые пути для самого себя.
Вообще, если в публикации правильно употребляются понятия TDD/BDD и не путаются с "покрытием тестами", то попытка сходу начать применять TDD/BDD кажется рискованной. Может быть лучше сначала начать с покрытия тестами?
Это не обязательно должен быть тот функционал, который от Вас требуют прямо сегодня-завтра. Покрывать тестами можно уже реализованный и отлаженный функционал, который по разумным соображениям кажется наиболее критичным для работы системы. Или тот функционал, который по статистике чаще всего выходит из строя в результате изменения системы. Затем можно перейти к подходу "нашел баг -> исправил -> покрыл тестом". Покрытие тестом можно сделать прямо по сценарию воспроизведения бага.
Может быть стоит оставить экстремальный подход работы через TDD/BDD на время, когда Вы сами сможете определять подходы к разработке? Если начать с постепенного покрытия тестами, то Вы и свои технические навыки применения инструментов повысите и система станет стабильнее. Реализацию же новых задач пока оставить как есть, покрывая их тестами, когда появится такая возможность.
BDD - это же вообще об общении постановщика задач (заказчика) с разработчиком. Покрытие тестами и сценарное тестирование - чуть другое :
(46) очень круто всё разложили:
- конечно, покрывать тестами существующий функционал - это против философии сначала тест потом код, но абсолютно согласен, что на этом можно неплохо набить руку. Сам грешу этим.
За конструктив огромная благодарность Вам!
- конечно, покрывать тестами существующий функционал - это против философии сначала тест потом код, но абсолютно согласен, что на этом можно неплохо набить руку. Сам грешу этим.
За конструктив огромная благодарность Вам!
(16)
Добрый день!
Спасибо за вашу статью и желание донести до сообщества информацию, что результаты разработки через тестирование являются более надежным и предсказуемыми, нежели результаты разработки без тестов вообще. Программист может быть уверен в том, что функции его модулей или обработок работают именно таким образом, как это было задумано. Разработка через тестирование очень сильно влияет на образ мышления программиста. К таким выводам я пришел, когда я программировал на ruby и затем php.
В данный момент мне необходимо дорабатывать функционал конфигурации УТП 1.2 которое работает на ОФ в режиме совместимости 8.2.13.
В саму конфигурацию я пока не лезу. Попробовал расширить функционал путем написания внешних обработок и понял, что мне очень не хватает инструментов для тестирования. Жуть как не хватает!
Очень не хватает ментора, который мог бы помочь преодолеть трудности на пути освоения, на мой взгляд правильного подхода к разработке 1С . В свою очередь обещаю быть полезным в ответ. Я очень люблю читать, но прямое общение с людьми незаменимо. Очень прошу откликнуться того, кто мог бы стать ментором для начинающего 1С программиста, а может и партнером или даже другом.
Абсолютно верно, только учить нужно тем, кто в этом гуру, а тем кто начинает путь, если есть желание, рассказывать каков он, этот путь.
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания!
Иначе, можно так научить, что переучивать дороже станет.
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания!
Иначе, можно так научить, что переучивать дороже станет.
Добрый день!
Спасибо за вашу статью и желание донести до сообщества информацию, что результаты разработки через тестирование являются более надежным и предсказуемыми, нежели результаты разработки без тестов вообще. Программист может быть уверен в том, что функции его модулей или обработок работают именно таким образом, как это было задумано. Разработка через тестирование очень сильно влияет на образ мышления программиста. К таким выводам я пришел, когда я программировал на ruby и затем php.
В данный момент мне необходимо дорабатывать функционал конфигурации УТП 1.2 которое работает на ОФ в режиме совместимости 8.2.13.
В саму конфигурацию я пока не лезу. Попробовал расширить функционал путем написания внешних обработок и понял, что мне очень не хватает инструментов для тестирования. Жуть как не хватает!
Очень не хватает ментора, который мог бы помочь преодолеть трудности на пути освоения, на мой взгляд правильного подхода к разработке 1С . В свою очередь обещаю быть полезным в ответ. Я очень люблю читать, но прямое общение с людьми незаменимо. Очень прошу откликнуться того, кто мог бы стать ментором для начинающего 1С программиста, а может и партнером или даже другом.
Статья не предполагала тематику вида: азы входа в TDD. Скорее показать реалии TDD при входе, в том числе, подготовить программистов к тому, что их старания, возможно, и это печально, не будут оценены положительно - это Ваша инициатива сделать Мир разработки 1С лучше. К этому нужно быть готовым и большой успех, если Ваша команда пропагандирует это.
Но над конструктивными замечаниями подумаю на будущее - как это грамотно оформить в виде статьи. Благодарю за конструктив!
Но над конструктивными замечаниями подумаю на будущее - как это грамотно оформить в виде статьи. Благодарю за конструктив!
ТДД Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторин
...
технология аникейщиков :)
...
технология аникейщиков :)
Мне не нравится как я пишу, и качество разработок моих (но я и видал код таких хомячков - что мои каракули = верх совершенства). Я пробовал и регулярно (но нечасто), пытаюсь мелкие задачи через "тдд" писать (по сермяжному, по доморощенному, но хоть как-то улучшить качество разработки). Но все упирается как раз в это "нужно вчера". Задачи для бизнеса (не в ИТ-компании!) возникают по инициативе бизнеса. А (небольшой) бизнес принципально не способен планировать разработку инструментария для решения его задач. Почти всегда это надо сейчас и вчера. И что делать? Конечно, понятно, что - плюем на все "тдд" и срочно пилим "как есть". Замкнутый круг.
(28) Когда пишешь под "сейчас и вчера", тогда и происходит реальное тестирование. Собственно, откуда ТДД произошло? Еще Дейкстра показал, что протестировать программу невозможно (начиная с некоторого объема). А тестировать надо. Значит, надо создать надежный остов (как - это другой вопрос) и помаленьку наращивать на него оттестированные кусочки мяса. В ИТ-компании это реальная проблема (релизы, версии, преемственность, сопровождаемость и т.п.). А в бизнесе появилась задача - делаем (пишем) канву. Даже распечаткой результатов не заморачиваемся. И юзерам в зубы. Через пару не дней, часов косяки налицо. Далее постепенно растим функционал. Так что никакого замкнутого круга.
(29) ээээ! это не катит когда цена ошибки велика. В работу надо отдавать "правильный" вариант. а ошибки иногда бывают ну не очень явные... и времени на тщательное программирование - нет совсем.. вот и костылишь - основное пишешь тщательно по возможности, а оно хреняк и сработало "неосновное" - а там конь не валялся, в целом-то вроде и правильно, но не очень...
(29)
Будет очень печально, когда встанет отгрузка со склада или еще какая-либо "процессно-значимая" фича.
Я был свидетелем разбора таких ситуаций у ген.дира, когда руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату и медленно намокали майки, а лица становились багрово-алыми.
Конечно же, это не норма такой разбор полетов - но повышать качество выпускаемых фич однозначно надо, моё ИМХО.
И юзерам в зубы. Через пару не дней, часов косяки налицо.
Будет очень печально, когда встанет отгрузка со склада или еще какая-либо "процессно-значимая" фича.
Я был свидетелем разбора таких ситуаций у ген.дира, когда руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату и медленно намокали майки, а лица становились багрово-алыми.
Конечно же, это не норма такой разбор полетов - но повышать качество выпускаемых фич однозначно надо, моё ИМХО.
(32)
руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату
Я про ИТ-фирмы не говорю. Три руководителя = перебор для любой другой фирмы.
Будет очень печально, когда встанет отгрузка со склада или еще какая-либо "процессно-значимая" фича.
Такое может быть только у менеджера. Руководители знают Козьму Пруткова: и при железных дорогах сохраняй двуколку. Внедрение новой фичи не может сопровождаться разрушением старых механизмов - ну, при нормальном руководстве, конечно.
Тестирование, всё же, не единственный вариант повышения качества разработки. Есть и другие, более независимые от команды и др. внешних факторов и не влияющие на скорость разработки в худшую сторону.
Есть, например, внутренняя автоматизация. У нас работает база-центр обменов и обработка обновления рабочей базы нединамически одной кнопкой (инструменты моего изготовления с учетом специфики).
Также есть повышения качества самого кода. Я не про унылые стандарты с ИТС (но и не против них). Отличная книга "Совершенный код" Макконела. Или написание запросов (почти) без конструктора (консоль запросов Инструментов Разработчика помогает автодополнением текста). Или освоение СКД в конце-концов (меньше кода -- лучше его качество).
Как-то экспериментировал с TDD, но моё впечатление, что более высокоуровневые приемочные тесты типа BDD это проще и более "по-1Сному", чем на каждую тривиальную функцию лепить тест по канонам классического TDD. (Но в те времена 1С-BDD было неразвито и как-то забросил тему.)
Есть, например, внутренняя автоматизация. У нас работает база-центр обменов и обработка обновления рабочей базы нединамически одной кнопкой (инструменты моего изготовления с учетом специфики).
Также есть повышения качества самого кода. Я не про унылые стандарты с ИТС (но и не против них). Отличная книга "Совершенный код" Макконела. Или написание запросов (почти) без конструктора (консоль запросов Инструментов Разработчика помогает автодополнением текста). Или освоение СКД в конце-концов (меньше кода -- лучше его качество).
Как-то экспериментировал с TDD, но моё впечатление, что более высокоуровневые приемочные тесты типа BDD это проще и более "по-1Сному", чем на каждую тривиальную функцию лепить тест по канонам классического TDD. (Но в те времена 1С-BDD было неразвито и как-то забросил тему.)
(33) Согласен с тем, что есть и другие способы повышения качества.
Лучше применять все варианты, причем системно, а не эпизодически.
Статический анализ кода, полная расширенная проверка, прогон через SonarBSL, дымовые тесты разных видов, продвинутые инструменты, отладка запросов, авторазвертывание, сервер непрерывной интеграции, сервер развертывания и т.п. и т.д.
Лучше применять все варианты, причем системно, а не эпизодически.
Статический анализ кода, полная расширенная проверка, прогон через SonarBSL, дымовые тесты разных видов, продвинутые инструменты, отладка запросов, авторазвертывание, сервер непрерывной интеграции, сервер развертывания и т.п. и т.д.
Некогда тесты писать, тут даже говнокодить не успеваешь, давай-давай :)
К сожалению, в большинстве случаев ситуация именно такая.
Серьезные подходы получается внедрять и они окупают себя только в серьезных продуктовых командах, которые востребованы в ограниченном количестве.
Где большие сложные продукты с большим количеством пользователей, поставленный цикл разработки и т.п. и т.д.
А не когда разработка идет в полтора лица, а цикл разработки разбит на случайные итерации от одного подзатыльника до другого с требованиями "на вчера".
К сожалению, в большинстве случаев ситуация именно такая.
Серьезные подходы получается внедрять и они окупают себя только в серьезных продуктовых командах, которые востребованы в ограниченном количестве.
Где большие сложные продукты с большим количеством пользователей, поставленный цикл разработки и т.п. и т.д.
А не когда разработка идет в полтора лица, а цикл разработки разбит на случайные итерации от одного подзатыльника до другого с требованиями "на вчера".
(40) Есть такая ситуевина.
Тут нужно автоматизироваться. Это почти без вариантов.
Т.е., нужно иметь возможность - куда-то выкладывать тесты. На сетевой ресурс, на интранет-гит, на внешний гитлаб, еще куда-то.
И нужны постоянные автоматические прогоны выложенных тестов на тестовом контуре. Результаты - должны публиковаться где-то. И/или пусть приходят по эл.почте.
Тогда это будет хорошим стимулом писать тестируемый код и сами тесты.
Это я себя так подбадриваю;)
Нужно уже собраться и написать какую-то такую сборочно-тестовую линию.
Я, в свое время, пошел по альтернативной ветке - не по учениям Серебряной пули. Написал и почти не развиваю обертку Ванесса-Раннер/Деплойка для Jenkins для автоматизации развертывания.
Хех, нужно уже написать линию тестирования.
Тут нужно автоматизироваться. Это почти без вариантов.
Т.е., нужно иметь возможность - куда-то выкладывать тесты. На сетевой ресурс, на интранет-гит, на внешний гитлаб, еще куда-то.
И нужны постоянные автоматические прогоны выложенных тестов на тестовом контуре. Результаты - должны публиковаться где-то. И/или пусть приходят по эл.почте.
Тогда это будет хорошим стимулом писать тестируемый код и сами тесты.
Это я себя так подбадриваю;)
Нужно уже собраться и написать какую-то такую сборочно-тестовую линию.
Я, в свое время, пошел по альтернативной ветке - не по учениям Серебряной пули. Написал и почти не развиваю обертку Ванесса-Раннер/Деплойка для Jenkins для автоматизации развертывания.
Хех, нужно уже написать линию тестирования.
(40)
Корень проблемы в том, что повышать свой профессиональный уровень хотят единицы, все остальные из "под палки".
Я приведу пример из своего управленческого опыта:
- объявил всем сотрудникам о том, что бюджет на обучение не ограничен (за это, конечно, особая благодарность моему руководителю, который "услашал" меня), выбирайте любые курсы - учитесь, в том числе с выездом в мск.
- только один сотрудник из 40 прошел обучение и сдал на спеца с первого разва в УЦ №1 за два года.
Вот так то!
Некогда тесты писать, тут даже говнокодить не успеваешь, давай-давай :)
Корень проблемы в том, что повышать свой профессиональный уровень хотят единицы, все остальные из "под палки".
Я приведу пример из своего управленческого опыта:
- объявил всем сотрудникам о том, что бюджет на обучение не ограничен (за это, конечно, особая благодарность моему руководителю, который "услашал" меня), выбирайте любые курсы - учитесь, в том числе с выездом в мск.
- только один сотрудник из 40 прошел обучение и сдал на спеца с первого разва в УЦ №1 за два года.
Вот так то!
Если на то пошло, то TDD своей основной и самой вкусной частью - про юнит-тестирование. А в 1С с юнитами несколько особая ситуация.
Половина настолько простые, что овчинка выделки не стоит, а половина настолько "завязанные", что тоже овчинка выделки не стоит (мокать устанет рука да и смысла особого нет).
Функциональные и интеграционные автоматические тесты - это да. Это реально полезно. Только классическое TDD не про них.
Половина настолько простые, что овчинка выделки не стоит, а половина настолько "завязанные", что тоже овчинка выделки не стоит (мокать устанет рука да и смысла особого нет).
Функциональные и интеграционные автоматические тесты - это да. Это реально полезно. Только классическое TDD не про них.
(63)
Макконелл, в том числе, писал о том, что код должен быть со "слабыми" связями.
Когда Вы изначально пишите тест, а после сам код, то это правило соблюдается как нельзя лучше.
Пока я вижу плюсы...наверняка, будут и сложности, но это скорее будет ограничением применимости технологии именно в 1С, но никак не посыл к отмене.
а половина настолько "завязанные", что тоже овчинка выделки не стоит (мокать устанет рука да и смысла особого нет)
Макконелл, в том числе, писал о том, что код должен быть со "слабыми" связями.
Когда Вы изначально пишите тест, а после сам код, то это правило соблюдается как нельзя лучше.
Пока я вижу плюсы...наверняка, будут и сложности, но это скорее будет ограничением применимости технологии именно в 1С, но никак не посыл к отмене.
(64) Удачи. Хотите попробовать фигней пострадать - ваше право.
А лично я бы сосредоточился не на эфемерном TDD в 1С, а хотя бы на простейших функциональных и интеграционных тестах.
Чтобы получать ответ на самые насущные вопросы:
- не сломался ли запуск 1С
- не сломалась ли работа форм
- не сломалась ли работа документов на тестовых наборах данных
Так даже до этого руки не доходят.
А лично я бы сосредоточился не на эфемерном TDD в 1С, а хотя бы на простейших функциональных и интеграционных тестах.
Чтобы получать ответ на самые насущные вопросы:
- не сломался ли запуск 1С
- не сломалась ли работа форм
- не сломалась ли работа документов на тестовых наборах данных
Так даже до этого руки не доходят.
(64)
Я бы акцент сделал на "ограничением применимости технологии именно в 1С".
ТДД был придуман на ООП. Именно там это работает так, как нужно.
Даже Серебряная Пуля пришла к тому, что чисто модульные тесты в 1С не панацея. И сместили разработку несколько в другое русло.
Пока я вижу плюсы...наверняка, будут и сложности, но это скорее будет ограничением применимости технологии именно в 1С, но никак не посыл к отмене.
Я бы акцент сделал на "ограничением применимости технологии именно в 1С".
ТДД был придуман на ООП. Именно там это работает так, как нужно.
Даже Серебряная Пуля пришла к тому, что чисто модульные тесты в 1С не панацея. И сместили разработку несколько в другое русло.
(64)
Вот когда в 1С будет возможно использование SOLID, DI, IOC без костылей, тогда и можно говорить о TDD.
Сам использовал TDD на ОПП. Реально стоящая вещь. Обеими руками за эту технологию. Но в реалиях 1С об этом можно только мечтать.
Макконелл, в том числе, писал о том, что код должен быть со "слабыми" связями.
Вот когда в 1С будет возможно использование SOLID, DI, IOC без костылей, тогда и можно говорить о TDD.
Сам использовал TDD на ОПП. Реально стоящая вещь. Обеими руками за эту технологию. Но в реалиях 1С об этом можно только мечтать.
(70)
Как раз наоборот. Именно когда с нуля. В любом случае, сразу с нуля писать код без предварительного обдумывания структуры и чернового плана, мягко говоря "код в никуда".
Именно TDD помогает сразу писать структурированный и покрытый тестами код. По другому просто сложно. И главное: код получается малосвязанный. TDD прямо навязывает использовать "включение" зависимостей.
Вот для исправления ошибок, это уже не TDD. И не каждый код можно "покрыть" модульными тестами. Да же не беру код завязанные на внешние факторы. Просто после "творишь" на это спагетти не всегда можно написать тест.
Сама методология ТДД - сначала тест, потом код не совсем подходит когда пишешь с 0.те "творишь".
Как раз наоборот. Именно когда с нуля. В любом случае, сразу с нуля писать код без предварительного обдумывания структуры и чернового плана, мягко говоря "код в никуда".
Именно TDD помогает сразу писать структурированный и покрытый тестами код. По другому просто сложно. И главное: код получается малосвязанный. TDD прямо навязывает использовать "включение" зависимостей.
Вот для исправления ошибок - вполне можно
Вот для исправления ошибок, это уже не TDD. И не каждый код можно "покрыть" модульными тестами. Да же не беру код завязанные на внешние факторы. Просто после "творишь" на это спагетти не всегда можно написать тест.
(71) писать в стиле ТДД вполне можно не писав при этом сами тесты.
когда творишь процедуры могут по 100 раз меняться - это нужно 100 х 500 тестов переписывать
PS творишь - это НЕ то когда пишешь по ТЗ. дорбавьте на форму реквизит "А". при его изменении должен измениться реквизит "Б"
когда творишь процедуры могут по 100 раз меняться - это нужно 100 х 500 тестов переписывать
PS творишь - это НЕ то когда пишешь по ТЗ. дорбавьте на форму реквизит "А". при его изменении должен измениться реквизит "Б"
(72)
Это как? Само название как бы говорит, что тесты вначале.
Если речь про попытку "писать в стиле ТДД" в 1С, то даже обсуждать это не буду. Уже говорил почему.
TDD это совсем не то, что вы себе представляете. Это нужно вникнуть в методологию. Научиться мыслить в нужном направлении.
Это как начать писать код под управляемые формы после обычных. Требуется перестраивать мышление, а не пытаться на УФ писать по привычке как на ОФ.
Чтобы не было недопонимания: это не прямая аналогия.
писать в стиле ТДД вполне можно не писав при этом сами тесты.
Это как? Само название как бы говорит, что тесты вначале.
Если речь про попытку "писать в стиле ТДД" в 1С, то даже обсуждать это не буду. Уже говорил почему.
TDD это совсем не то, что вы себе представляете. Это нужно вникнуть в методологию. Научиться мыслить в нужном направлении.
Это как начать писать код под управляемые формы после обычных. Требуется перестраивать мышление, а не пытаться на УФ писать по привычке как на ОФ.
Чтобы не было недопонимания: это не прямая аналогия.
(74) это не TDD.
Вся прелесть TDD в том, что вначале пишется тест того, что должно получиться. Заметьте, не как, а что. Запускается тест. Если тест проходит, значит есть ошибка. Именно так. Ошибка!
Первый тест никак не должен проходить.
Если тест не прошел, то пишется простейшая реализация модуля. Ровно такая, чтобы тест прошел.
Дальше интересней. При необходимости пишется тест проверяющий пограничные значения. И самое главное. Делается рефакторинг того простейшего кода, который был написан только для прохождения теста. При каждом изменении кода прогоняется тест. Этим мы отслеживаем работоспособность кода.
Пример: Нужно создать метод деления чисел.
1. Пишем тест: Проверяем, что 6/2=3
2. Проверяем метод. Ошибка. Отлично.
3. Пишем код: Возврат 3. Да, в данном случае утрированно, но в общем смысле именно так в простейшем случае. Не пытаемся полностью написать сложный метод.
4. Проверяем. Тест проходит.
5. Пишем тесты на пограничные условия. Типа деления на 0. И другие выборочные значения.
6. Проверяем. Не все тесты проходят.
7. Изменяем код под новые тесты.
8. Тесты проходят.
9. При необходимости делаем рефакторинг. Цель: оптимизировать вычисление.
10. Прогоняем тесты. Если проходят, то готово. Иначе повторяем с п.7.
Вся прелесть TDD в том, что вначале пишется тест того, что должно получиться. Заметьте, не как, а что. Запускается тест. Если тест проходит, значит есть ошибка. Именно так. Ошибка!
Первый тест никак не должен проходить.
Если тест не прошел, то пишется простейшая реализация модуля. Ровно такая, чтобы тест прошел.
Дальше интересней. При необходимости пишется тест проверяющий пограничные значения. И самое главное. Делается рефакторинг того простейшего кода, который был написан только для прохождения теста. При каждом изменении кода прогоняется тест. Этим мы отслеживаем работоспособность кода.
Пример: Нужно создать метод деления чисел.
1. Пишем тест: Проверяем, что 6/2=3
2. Проверяем метод. Ошибка. Отлично.
3. Пишем код: Возврат 3. Да, в данном случае утрированно, но в общем смысле именно так в простейшем случае. Не пытаемся полностью написать сложный метод.
4. Проверяем. Тест проходит.
5. Пишем тесты на пограничные условия. Типа деления на 0. И другие выборочные значения.
6. Проверяем. Не все тесты проходят.
7. Изменяем код под новые тесты.
8. Тесты проходят.
9. При необходимости делаем рефакторинг. Цель: оптимизировать вычисление.
10. Прогоняем тесты. Если проходят, то готово. Иначе повторяем с п.7.
(74) Не. TDD - это достаточно специфическая штука.
Просто его настолько часто поминают всуе, когда разговор заходит за юнит-тестирование, что люди которые не сильно в теме начинают их как синонимы использовать. И юнит-тесты и написание хорошего кода, в том числе легко тестируемого - это все и без TDD прекрасно себя чувствует.
Просто его настолько часто поминают всуе, когда разговор заходит за юнит-тестирование, что люди которые не сильно в теме начинают их как синонимы использовать. И юнит-тесты и написание хорошего кода, в том числе легко тестируемого - это все и без TDD прекрасно себя чувствует.
(77) "Писать в стиле ТДД" - если при этом вы не пишите тестов ДО кода, то фраза будет некорректна.
Если вы пишите хороший тестируемый код и даже пишите потом отличные тесты на этот код - то так и говорите. Не нужно приговаривать про TDD - он никакого отношения к этому не имеет, вы только введете людей в заблуждение. Это вообще разные плоскости.
TDD - это всего лишь идеология использования тестов в качестве ТЗ. Формулируете требования, воплощаете их в тестах и только потом реализуете код, удовлетворяющий этим требованиям. Именно в таком порядке. Тесты могут быть говно, код может быть отстой, зато можно смело заявлять, что вы ведете разработку по TDD и это будет чистая правда.
Если вы пишите хороший тестируемый код и даже пишите потом отличные тесты на этот код - то так и говорите. Не нужно приговаривать про TDD - он никакого отношения к этому не имеет, вы только введете людей в заблуждение. Это вообще разные плоскости.
TDD - это всего лишь идеология использования тестов в качестве ТЗ. Формулируете требования, воплощаете их в тестах и только потом реализуете код, удовлетворяющий этим требованиям. Именно в таком порядке. Тесты могут быть говно, код может быть отстой, зато можно смело заявлять, что вы ведете разработку по TDD и это будет чистая правда.
(79) Апологеты утверждают что да - используют. Типа фишка даже не столько (или не только) в покрытии кода тестами как таковом, сколько в особом методе мышления и подходе к разработке. Который форсит думать о правильных вещах вовремя и из которого вытекает куча полезных плюшек.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|