Новичок в TDD

Программирование - Практика программирования

TDD xUnit Vanessa разработка через тестирование.

50
Краткие итоги первых шагов при разработке в 1С через TDD.

ВНИМАНИЕ: Автор статьи не несёт ответственности за причиненный ущерб Вашим надеждам и/или иным душевным страданиям после прочтения данной публикации. Если Вы человек с тонкой душевной организацией, планирующей применять TDD, Вам лучше отказаться от прочтения или Вам гарантированы знания, которыми Вы можете умело распорядиться. Всем удачи в получении новых знаний! ;-)

 

Всем участникам сообщества мой пламенный привет!

    Будет много букв и требующих вдумчивости и осмысления предложений, налейте приятный для Вас напиток, выберите удобное положение и обязательно оглянитесь!

Оглянуться обязательно, за спиной может быть Руководитель.

Начнём...

 

1. Вводная часть.

    Не часто, но бывают статьи на «Инфостарт» о том, как правильно вести разработку определенного функционала через тестирование, то есть по промышленным стандартам.

    В основном, это статьи  тех, кто двигает и популяризирует эту тему, тот, кто несёт знамя победы над злом не протестированных автоматически релизов и (или) фич. На текущий момент в арсенале разработчика 1С есть один инструмент, включающий в себя функционал:

1. Cценарного тестирования - Vanessa Behavior;

2. Модульного тестирования - xUnit.

    Для тех, кто не в теме, до определенного момента эти два инструмента развивались каждый сам по себе, а с текущего года - объединились в один проект, что абсолютно закономерно, с моей точки зрения.

Мне всегда нравилось быть на передовой современных технологий в разработке ПО, благо для этого есть масса информации в интернете, да и скорость интернета позволяет, и давно канули в лету времена, когда ты занимал домашний телефон и объяснял своей семье такое нахальство надобностью открыть всего лишь одну страницу из глобальной паутины и почему это важнее звонка Авдотьи Поликарповны.

Сегодня все возможности открыты, было бы желание, а время найдётся.

Но вернёмся всё-таки к нашей теме.

    Итак, не обошёл стороной и я данный инструментарий и в дальнейшем на протяжении всей статьи понемногу я буду использовать аналогии, так нередко применяющиеся в разработке ПО, чтобы через призму простых житейских вопросов донести свой посыл.

    Начнём с того, чтобы применять какой-либо инструментарий нужно учиться, учиться и, самое главное, наконец-таки научиться и не абы как, а методически правильно, ведь мы не садимся на автомобиль и не едем задним ходом от дома до работы, хотя если кто-то в этом признается наконец-то сам себе или открыто в комментариях, респект миру неординарных личностей, Вас мало, но Вы интересны.

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

    Многие руководители/управленцы грешат тем, что бросают новичка в омут создания новой фичи не рассказывая, как, с помощью чего и, главное, методически правильно применить тот или иной метод, инструментарий или функционал. 

Это тема отдельной статьи, не будем об этом, но последствия этого как в ближайшей, так и в долгосрочной перспективе печальны: от демотивации и увольнения, до устоявшегося навсегда мнения - так правильно, я так уже делал.

 

2. Начинаем изучать.

    Конечно, первое, что приходит на ум - это гуглить, но не тратьте время зря - ничего не будет продуктивного и бесплатно, именно в контексте входа в данную технологию.

   Есть описание и справка инструментов на GitHub, но для меня взять нахрапом было сложно по нескольким причинам, надеюсь, разработчики услышат меня:

  1. Прежде чем приступить к использованию инструмента мне хочется знать, как именно его применять в той или иной ситуации от начала и до конца. Представьте, если бы Вы учились водить автомобиль так: инструктор запускает двигатель, трогается и предлагает Вам на ходу пересесть, Вы пересели и после того, как доехали, так же на ходу вернулись в своё кресло. Да, Вы научитесь рулить, но не будете знать, как завести и тронуться с места. Это ни в коем случае не камень в огород тех, кто эти инструменты поддерживает и прикручивает новые фичи (ребятам - низкий поклон за их труд) - это конструктивное дополнение. Нужны сквозные примеры от начала и до конца. Сейчас, используя инструментарий, мне, конечно же, в разы легче понимать справку и использовать методы, но сил было затрачено негуманно и неоправданно много, и если мы, как сообщество 1С, хотим поднимать качество разработки, просто необходимо снижать порог для входа;
  2. Я совсем не понимал отличия xUnit от Vanessa Behavior от слова СОВСЕМ, а когда не понимаешь, тогда и применяешь глупо - хотелось бы иметь сравнительную таблицу с пояснениями плюсов и минусов использования той или иной возможности;
  3. Для применения Vanessa Behavior желательно знать инструментарий Visual Studio Code (VSC) и GitHub, как-то же Вам нужно будет работать и клонировать инструментарий - я, к сожалению, даже краткого описания этого не нашёл и просто не знал, что нужен VSC и это было, поверьте мне, одним из камней преткновения.

Конечно, я четко понимаю, что когда ты обладаешь системным знанием: как подготовить окружение, для чего и как использовать - это уже уровень, при котором такие нюансы кажутся элементарными, но для новичков это тернистый путь, которые проходят далеко не все.

 

3. В предвкушении светлого будущего.

    Итак, Вы всё осилили и у Вас даже начинает получаться, Вы чувствуете, как Ваш сон улучшается после каждого очередного «безбагового» релиза.

    Это фичи других разработчиков падают на «продуктиве», но не Ваши, и если тесты написано грамотно, ЭТО ТАК И ЕСТЬ

- я рассуждаю не как теоретик, вдохновлённый прочитанными книгами о промышленной разработке и насмотревшийся видео, а как практик, хоть и делающий в этом направлении не первый,  но уже уверенно второй шаг.

    И вот Вы, почувствовавший блаженство, вдруг начинаете ловить сначала косые взгляды сотрудников, а затем и претензии руководителя, почему разработка затягивается в два, а то и в три раза.

    На первоначальном этапе это действительно может быть даже в три раза и более. Инструменты новые, нужно постоянно разбираться, пробовать, оптимально использовать и так далее, со временем скорость, конечно же, будет возрастать, а время на разработку через тестирование уменьшаться, но при всем при этом, если Вы будете разрабатывать без TDD, будет быстрее - это факт.

   И тут самое главное непонимание многими, где же профит, а профит системный и на поверхности: если компания крупная, дорожит своей репутацией, умеет считать деньги за часы работы тестировщиков и разработчиков, то все очень просто:

  1.  Экономия на количестве циклов «разработка - отладка - тестирование»;
  2.  Исключение багов на «продуктиве» и, как следствие, снижение репутационных рисков.

    В итоге, стабильный релиз, все рады, разработчики психологически спокойны, тестировщики в умиротворении, подписанный акт, деньги, отсутствие кассовых разрывов у компании.

    Но это если в розовых очках, теперь расскажу Вам опыт тех компаний, где мне посчастливилось работать и приобрести этот ценный и  разносторонний опыт.

 

4. Реалии немного сложнее...

Я намеренно не буду раскладывать все нумерованным списком с пояснением нюансов разработки и характеристикой конфигураций конкретной компании именно потому, что не хочется хоть как-то персонализировать и задеть самолюбие моих прошлых руководителей.

А история такая:

    Это были три достойно крупных региональных компании и компания-франчайзи. Думаю про «франч» писать не стоит - Вы сами понимаете, а вот в крупных компаниях ещё интереснее:

Никому, ни одному руководителю не нужна была эта технология именно из-за увеличения локальных сроков разработки.

    Несмотря на огромные БД и критичность багов в «продуктиве», на объяснения всех плюсов и временных трудностей, ссылок на доказательство того, что эволюция – это благо, после очередного совещания приходил Руководитель и все необходимо было делать СРОЧНО И ВЧЕРА. И всегда мне приходилось применять технологию «полуподпольно», чтобы хоть как-то соответствовать.

Думать и биться об стену, почему так Вселенная несправедлива, мне не пришлось, так как, имея управленческий опыт, я всегда четко понимал банальные причины этого:

1. Галочка важнее качества. Качество «дофиксим», необходимо оставаться «хорошим» перед Заказчиком, как внутренним, так и внешним;

2. Все новое всегда отрицается, особенно, когда ты это не умеешь делать;

3. Отсутствие желания учиться новому, а зачем? Есть зона комфорта, все хорошо в матрице этого человека и, возможно, даже он считает себя специалистом с большой буквы;

4. Ну и психологию никто не отменял, умнее, значит, конкурент, а высокооплачиваемое место терять никому не хочется в наше неспокойное время и век ипотеки, хотя никогда никого не «подсиживал» и целей таких не имею.

    Ещё один  интересный момент  заключается в том, что многие разработчики вообще не проявляли инициативы изучить инструмент, даже работая со мной в одной компании. Казалось бы, мне пришлось пройти нелегкий путь в изучении, а тут рядом, под боком, спрашивай - расскажу и покажу, но нет. Абсолютно.

    Скорее, высказывания: зачем нам это надо, и так все более-менее хорошо, динамические обновления за день по пять раз –  это норма, НОРМА - как бы сказала известная телеведущая!

    Но это история про команды, в которых я трудился. Конечно же, мне было очень интересно где же все-таки эта философия прижилась? Я собрал статистику по вакансиям, которые опубликованы на известном всем нам ресурсе.

 

5. Неужели везде так?

Так вот, я сделал небольшой опросник работодателей, которые меня приглашали на собеседование или откликался я сам для того, чтобы выяснить, применяет ли команда данный стек технологий.

Статистика печальна, из 30 команд:

  1. В одной есть использование практики TDD, но НЕ описанными выше инструментами;
  2. В одной есть понимание и слышали об этом;
  3. Остальные - это работа по классике жанра через РМП(с) - разработка через муки пользователя.

Термин РМП(с) придуман мною и введён в словарный запас сразу после знакомства с TDD.

И как же быть? - спрашивал я себя:

только системное мышление, только ИТ-директор, собственник ИТ-компании, возможно, сможет это продавливать в коллективах собственным ли опытом, опытом инициативного коллеги, устраивать разборы полетов, почему статистика багов по «фичам» через тестирование в разы меньше, но это должно быть, ибо шаг вперёд –  это развитие и эволюция, а не повседневная рутина, которую также можно и нужно разнообразить.

    И порой от самих программистов 1С я слышу высказывания о том, что 1С –  это нехорошо, зачем я стал одинэсником, тут не все как на жава, сишарп, питон, руби шмуби - специально сохранил написание на русском для придания колорита - но никто при этом не делает усилий в изучении стандартов разработки для того, чтобы код выглядел более лаконично, никто не знает применяемые для 1С инструменты TDD, но зато способны к всеобъемлющей критике - изучайте, дерзайте, применяйте 1С там, где её «конёк», для чего она и была создана и будет Вам внутренняя гармония.

 

6. Если всё-таки хотите

...разрабатывать в 1С через тестирование:

  • Самый правильный вариант - найти команду, пропагандирующее TDD;
  • Чуть сложнее чем найти компанию-инкубатор - создать команду самому с нуля в какой-либо растущей компании, или, например, у компании все задачи решались силами внешнего разработчика, выросли, хотят своё подразделение;
  • Сложно - «заразить» существующую команду самому или через руководителя.

В заключение хотелось бы ещё раз выразить огромную благодарность всем тем, кто помогал мне в освоении данного инструмента, низкий поклон и искреннее уважение тем, кто придумал, разработал, довёл до логического и работающего состояния и также занимается поддержкой xUnit и VanBe.

 

    Очень хорошая статья известного сообществу разработчика. Теоретические азы + обзор инструментов.

    Так же, кому интересна эта философия и есть возможность, купите тематические курсы по промышленной разработке от silver bulleters, они есть на инфостарте (не сочтите за рекламу, только в целях помощи).

 

Ну что же, думаю достаточно для первого раза.

Всему сообществу 1С добра!

 

50

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. Сурикат 182 08.10.18 15:41 Сейчас в теме
Поспорю с тезисом:
Никому, ни одному руководителю не нужна была эта технология именно из-за увеличения локальных сроков разработки.

Если договорится, что выполненной задача считает тогда, когда пользователь может нормально работать, то сроки разработки одинаковые. Их только считают неправильно.

А так спасибо за труд =)

+ втянутся в тестирование неочень легко, надо хотя бы пару книжек прочитать и научиться писать тестируемый код. А самому это довольно-таки тяжело.
JohnyDeath; Alligator84; +2 Ответить
2. Alligator84 52 08.10.18 15:44 Сейчас в теме
Абсолютно согласен только тогда, когда твой руководитель замыкает весь цикл разработки, а когда руководитель разработки ПО стремится быстрее отдать в отдел тестирования, то тут его мало интересует качество кода до того момента, пока ему в KPI не поставят показатель количества возвратов на доработку!
3. artbear 1084 08.10.18 16:16 Сейчас в теме
Олег, интересная статья.

Только названия инструмента-наследника от VB и xUnitFor1C я так и не увидел :)
Alligator84; +1 Ответить
6. Alligator84 52 08.10.18 16:30 Сейчас в теме
(3) А вот и уважаемый мною, artbear!

Проект объединен в единый общий репозиторий ADD

ADD - объединенный проект содержит в себе

BDD - bddRunner
TDD - tddRunner
единые расширения для тестирования


(4)
Мне понравился термин "РМП" - разработка через муки пользователя, :) помимо многих мыслей.

Да уж, хоть как то сделать легче пользователям - это научиться правильному подходу самому!
4. artbear 1084 08.10.18 16:22 Сейчас в теме
Мне понравился термин "РМП" - разработка через муки пользователя, :) помимо многих мыслей.
ЧерныйКот; DenisCh; Alligator84; +3 Ответить
8. Alligator84 52 08.10.18 16:59 Сейчас в теме
(4)
Мне понравился термин "РМП" - разработка через муки пользователя, :) помимо многих мыслей.


Новый холивар: TDD vs DUS

TDD - test driven development
DUS - development through user suffering
42. VladimirL 800 09.10.18 18:15 Сейчас в теме
5. ivanov660 891 08.10.18 16:26 Сейчас в теме
Проблема в головах трудно решаемая задача, но решаемая)
Также, на мой взгляд, существенные трудности вносит некоторая не совместимость подхода TDD с 1С, его можно относительно эффективно использовать при части решаемых задач.
Alligator84; +1 Ответить
7. Alligator84 52 08.10.18 16:31 Сейчас в теме
(5) Не соглашусь в данный момент, на текущий момент не встречал таких задач, если приведете пример, будет круто!
13. ivanov660 891 08.10.18 17:21 Сейчас в теме
(7)Во-первых, если внимательно читали, то я утверждаю, что его эффективно использовать при части решаемых задач. Это значит, что деньги/время/эффективность при некоторых условиях перевешивают весы в другую сторону.
Во-вторых, расскажите мне как вы обходите отсутствие возможность создать mock объекты в 1С.
Alligator84; +1 Ответить
14. Alligator84 52 08.10.18 17:32 Сейчас в теме
(13)
mock объекты в 1С

А пока никак на данной ветке своей эволюции в разработке через TDD.
Я прочитал Вашу статью и нашел много полезностей, которые еще предстоит осознать и пощупать на практике.
Но при всем при этом, тому функционалу, который мне приходилось обвязать тестами, не требовались ни подставные объекты, ни заглушки.
Я даже не представляю пока как их применить в тестировании в 1С.
Есть статьи на эту тему или достойная книга на Ваш взгляд?
20. ivanov660 891 08.10.18 21:16 Сейчас в теме
(14)
1. В некотором приближении макет можно назвать мок объектом.
2. В рамках TDD и 1С я видел только статьи от Артура Аюханова и Ко.
3. По-моему опыту, эффективно обвязывать тестом блоки функций (относительно большой кусок). Обвязывать маленькую функцию слишком времязатратно и не эффективно (время/деньги/качество/люди).
4. Читать другие книги по TDD тяжело, т.к. проекция примеров в 1С нельзя спроецировать один в один (Книга «Экстремальное программирование: разработка через тестирование»).
5. У нас в компании, я в ближайшее время планирую провести вебинар посвященный тестированию юнит и TDD, думаю, я выложу на youtube канале некоторую интерпретацию некоторое время после.
Alligator84; +1 Ответить
25. Сурикат 182 08.10.18 22:07 Сейчас в теме
(20)
А по-моему наоборот. Легко получается писать unit-тесты, если функция маленькая и имеет мало зависимостей. Например, очень просто написать тест на функцию, чьими параметрами будет выступать пара документов и элементов справочников. Тогда и макеты не нужны. Можно создать пару элементов справочника только с нужными зависимостями.

К примеру, документ реализация, 2 номенклатуры и один склад. И мы уже можем протестировать движения документа по складскому контуру.

Т.е. в качестве границ выступают не интерфейсы (к примеру), а метаданные. И чем к меньшему кол-ву метаданных мы сведем, тем более тестируемый и простой получится код.

Если писать unit-тесты сразу, то получается не так трудозатратно и выигрыш больше. Но большинство существующего кода 1с тестируется плохо, с вами согласен. Зависимость от БД слишком велика.
43. ImHunter 21 09.10.18 19:29 Сейчас в теме
(20)
Насчет моков. У нас тоже достаточно большое поле возможностей и фантазии.
1. Тесты, обычно, обрамляются началом/откатом транзакции. Можно создать свой тестовый документ/справочник, записать и использовать его ссылку. При откате транзакции - будто ничего и не было.
2. Примерно тоже, что и п.1, только объект можно заполнить какими-то предварительно сериализованными данными.
3. Как иногда в типовых, подменять Структурой.
44. ImHunter 21 09.10.18 19:34 Сейчас в теме
(20) Насчет
4. Читать другие книги по TDD тяжело, т.к. проекция примеров в 1С нельзя спроецировать один в один (Книга «Экстремальное программирование: разработка через тестирование»).

Ну не знаю... Как по мне, эта книжка достаточно правильно заряжает. И главное, вдалбливает режим "красный-зеленый-рефакторинг". Даже если этого не соблюдаешь, то как-то всегда помнится об этом.
9. JohnyDeath 291 08.10.18 17:06 Сейчас в теме
Хорошая статья. Знакомо до боли.
Но я так и не понял, чем всё закончилось? Автор, где сейчас работаешь? Всё также подпольно пишешь и запускаешь тесты? Или уже заразил всю команду зелеными кружочками?
Alligator84; +1 Ответить
10. Alligator84 52 08.10.18 17:08 Сейчас в теме
(9)
Но я так и не понял, чем всё закончилось?

Надеюсь не закончится еще очень долго!

(9)
Всё также подпольно пишешь и запускаешь тесты?

Так точно.

(9)
Или уже заразил всю команду зелеными кружочками?

К сожалению, нет...никому кодить в два раза больше строк кода не хочется.
JohnyDeath; +1 Ответить
11. JohnyDeath 291 08.10.18 17:14 Сейчас в теме
(10) Дымовые тесты же всем показывал?
Вообще, когда/если ты уйдешь с текущей работы, к тебе будут обращаться с вопросами про вю эту магию.
Сейчас даже немножко попроще - и материалов полно (платных и бесплатных), и инструменты заметно подтянулись + вышли новые.
Но всем надо "здесь и сейчас", а играть "вдлинную" никто не хочет или не умеет.
UniversaLL; Alligator84; +2 Ответить
12. Alligator84 52 08.10.18 17:19 Сейчас в теме
Да меня после зеленых кружочков никто не понял, почему сроки по новой подсистеме неоправданно высокие!

А если бы про "дымовые" заикнулся - все бы расценили как попытку поджёга офиса;-)

(11)
Сейчас даже немножко попроще - и материалов полно (платных и бесплатных), и инструменты заметно подтянулись + вышли новые.

Так и есть, заниматься можно постоянно повышая свой профессиональный уровень.

(11)
Но всем надо "здесь и сейчас", а играть "вдлинную" никто не хочет или не умеет.

Причины, на мой взгляд, очевидны, я их описал в публикации и изменить парадигму в коллективе сможет только тот, кто будет заточен на качество с большой буквы К.
23. TODD22 17 08.10.18 21:29 Сейчас в теме
(11)
Вообще, когда/если ты уйдешь с текущей работы, к тебе будут обращаться с вопросами про вю эту магию.

Или забросят, если никому не интересно, то продолжать не будут. Пробовал внедрять "промышленные подходы" после аналогичного курса. Всё из под палки, потом и самому всё это надоело.
21. ivanov660 891 08.10.18 21:24 Сейчас в теме
(10)
К сожалению, нет...никому кодить в два раза больше строк кода не хочется.

Я разработчика спрашиваю: "как ты докажешь, что твое решение правильное/работоспособное?" Хороший ответ, у меня есть тест)
UniversaLL; Alligator84; +2 Ответить
82. kuzyara 522 19.10.18 19:56 Сейчас в теме
(21)
Я разработчика спрашиваю: "как ты докажешь, что твое решение правильное/работоспособное?"

есть же внутренняя приёмка (или демо в скраме)

А самописный тест может отличаться от конечных ожиданий. И да, тест <> правильное решение.
15. grumagargler 458 08.10.18 18:33 Сейчас в теме
Если будет больше статей практического характера, то и не будет, постоянного, простите, нытья, о том, что тестирование - круто, но большинство настолько слабы душой, что не тянут. Нет, ну серьёзно, если есть желание двигать тему - нужны тематические материалы, а не рассказы: "никто не использует тестирование, а ведь это так круто, ведь я попробовал и у же получается".
mytg; VladimirL; tsukanov; zqzq; CyberCerber; kuntashov; Adam12345678; JohnyDeath; Alligator84; +9 Ответить
16. Alligator84 52 08.10.18 18:38 Сейчас в теме
(15) Абсолютно верно, только учить нужно тем, кто в этом гуру, а тем кто начинает путь, если есть желание, рассказывать каков он, этот путь.
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания!
Иначе, можно так научить, что переучивать дороже станет.
17. grumagargler 458 08.10.18 18:45 Сейчас в теме
(16) Ждем следующей статьи, не нужно обучающей, просто поделитесь практическим примером наработок, к чему пришли, какие сложности и т.д. с точностью до строки кода. Понимаете, тема тестирования уже сильно взбудоражена и до нас вами, и не очень большое количество статей, где об этом рассказывается на практических примерах, начинает раздражать большую гвардию программистов, которые пытаются и не получается (не у всех хватает выдержки, но и ведь она не обязательно должна у них быть!)
so-quest; kuntashov; Adam12345678; Alligator84; +4 Ответить
46. VladimirL 800 09.10.18 22:06 Сейчас в теме
(16)
учить нужно тем, кто в этом гуру
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания

Учить и делиться практическим опытом - разные вещи. Ждать гуру для этого не стоит, можно не дождаться )) "Нет взрослых, кроме нас самих". Что мы публикуем и чем делимся друг с другом, то и становится фундаментом для нашего развития. Все использованные Вами инструменты относятся к миру Freeware и Open Source. А в нём всё именно так и работает.


У Вас наверняка были какие-то конкретные сложности при настройке инструментов. Вы их как-то обходили. Выполняли конкретные действия. Наверняка есть подборка источников информации. Их можно сгруппировать по тематикам. Привести пример своего, пускай и небольшого, теста. Снять скриншоты. И сделать публикацию на Инфостарте. Которую затем можно будет сколько угодно редактировать и дополнять по результатам обсуждения в комментариях.


Не хватает практических примеров? Да, есть такое. Многие публикации действительно пишутся на недосягаемом уровне абстракции и не содержит последовательности шагов от начала до конца для достижения цели. Так значит ниша ещё пуста! Заполняйте её.


Это позволило бы добиться сразу нескольких целей:

1) Повысить интерес к теме и её популярность. Это было бы гораздо лучше демотивации от утверждений о ненужности тестирования руководству. То, что 1С вместе со многими руководителями растут с низовых слоев бизнеса, где и планирование и качество не в чести, итак известно. Но ситуация улучшается, во многом благодаря сообществу и авторам, которые развивают эту тему.

2) Дать понять другим авторам, куда лучше копать, когда они будут делать публикации на эту тему. Может быть это поможет контрибьюторам проекта улучшить справку по инструментам. Между прочим в обработке bddRunner сейчас есть довольно хорошая встроенная справка.

3) Сами же лучше систематизируете и структурируете для себя информацию. Под чем-то подведете черту. Где-то увидите новые пути для самого себя.



Вообще, если в публикации правильно употребляются понятия TDD/BDD и не путаются с "покрытием тестами", то попытка сходу начать применять TDD/BDD кажется рискованной. Может быть лучше сначала начать с покрытия тестами?

Это не обязательно должен быть тот функционал, который от Вас требуют прямо сегодня-завтра. Покрывать тестами можно уже реализованный и отлаженный функционал, который по разумным соображениям кажется наиболее критичным для работы системы. Или тот функционал, который по статистике чаще всего выходит из строя в результате изменения системы. Затем можно перейти к подходу "нашел баг -> исправил -> покрыл тестом". Покрытие тестом можно сделать прямо по сценарию воспроизведения бага.

Может быть стоит оставить экстремальный подход работы через TDD/BDD на время, когда Вы сами сможете определять подходы к разработке? Если начать с постепенного покрытия тестами, то Вы и свои технические навыки применения инструментов повысите и система станет стабильнее. Реализацию же новых задач пока оставить как есть, покрывая их тестами, когда появится такая возможность.

BDD - это же вообще об общении постановщика задач (заказчика) с разработчиком. Покрытие тестами и сценарное тестирование - чуть другое : https://www.youtube.com/watch?v=JnoZbbYZeeI
CSiER; zqzq; Alligator84; grumagargler; +4 Ответить
48. Alligator84 52 10.10.18 08:07 Сейчас в теме
(46) очень круто всё разложили:
- конечно, покрывать тестами существующий функционал - это против философии сначала тест потом код, но абсолютно согласен, что на этом можно неплохо набить руку. Сам грешу этим.

За конструктив огромная благодарность Вам!
VladimirL; +1 Ответить
83. kuzyara 522 19.10.18 20:02 Сейчас в теме
(48) Покажите хотя бы один ваш ""тест"? ;)
18. artbear 1084 08.10.18 18:59 Сейчас в теме
Да, более практической части, конечно, не хватает.

Практики и технических деталей нужно больше, конечно.
Adam12345678; +1 Ответить
19. Alligator84 52 08.10.18 19:08 Сейчас в теме
Статья не предполагала тематику вида: азы входа в TDD. Скорее показать реалии TDD при входе, в том числе, подготовить программистов к тому, что их старания, возможно, и это печально, не будут оценены положительно - это Ваша инициатива сделать Мир разработки 1С лучше. К этому нужно быть готовым и большой успех, если Ваша команда пропагандирует это.

Но над конструктивными замечаниями подумаю на будущее - как это грамотно оформить в виде статьи. Благодарю за конструктив!
22. DrZombi 08.10.18 21:26 Сейчас в теме
ТДД Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторин

...
технология аникейщиков :)
24. CheBurator 3563 08.10.18 22:04 Сейчас в теме
"много букв" - это предупреждение для молодежи, читающей только твиттер? ;-0
26. CheBurator 3563 08.10.18 22:18 Сейчас в теме
Следует ли материал трактовать так, что ТДД неприменимо в маленьких (насколько каких?) компаниях, обслуживаемых 1-2 1Сниками, которые не занимаются промышленной разработкой на продажу..?
27. Alligator84 52 08.10.18 22:22 Сейчас в теме
Конечно же нет, и один разработчик может покрыть тестами свою конфу и спать спокойно!
Когда все фичи покрыты тестами, то и вносить изменения в разы проще, не боясь выпускать релиз в production!
84. kuzyara 522 19.10.18 20:08 Сейчас в теме
(27)
один разработчик может покрыть тестами свою конфу

Свою? Один? Полностью всю конфу? Вы сильно преувеличиваете.
28. CheBurator 3563 08.10.18 22:23 Сейчас в теме
Мне не нравится как я пишу, и качество разработок моих (но я и видал код таких хомячков - что мои каракули = верх совершенства). Я пробовал и регулярно (но нечасто), пытаюсь мелкие задачи через "тдд" писать (по сермяжному, по доморощенному, но хоть как-то улучшить качество разработки). Но все упирается как раз в это "нужно вчера". Задачи для бизнеса (не в ИТ-компании!) возникают по инициативе бизнеса. А (небольшой) бизнес принципально не способен планировать разработку инструментария для решения его задач. Почти всегда это надо сейчас и вчера. И что делать? Конечно, понятно, что - плюем на все "тдд" и срочно пилим "как есть". Замкнутый круг.
fancy; kote; +2 Ответить
29. Арчибальд 2705 08.10.18 23:36 Сейчас в теме
(28) Когда пишешь под "сейчас и вчера", тогда и происходит реальное тестирование. Собственно, откуда ТДД произошло? Еще Дейкстра показал, что протестировать программу невозможно (начиная с некоторого объема). А тестировать надо. Значит, надо создать надежный остов (как - это другой вопрос) и помаленьку наращивать на него оттестированные кусочки мяса. В ИТ-компании это реальная проблема (релизы, версии, преемственность, сопровождаемость и т.п.). А в бизнесе появилась задача - делаем (пишем) канву. Даже распечаткой результатов не заморачиваемся. И юзерам в зубы. Через пару не дней, часов косяки налицо. Далее постепенно растим функционал. Так что никакого замкнутого круга.
30. CheBurator 3563 09.10.18 04:01 Сейчас в теме
(29) ээээ! это не катит когда цена ошибки велика. В работу надо отдавать "правильный" вариант. а ошибки иногда бывают ну не очень явные... и времени на тщательное программирование - нет совсем.. вот и костылишь - основное пишешь тщательно по возможности, а оно хреняк и сработало "неосновное" - а там конь не валялся, в целом-то вроде и правильно, но не очень...
31. CheBurator 3563 09.10.18 04:02 Сейчас в теме
(30) Понятно, что от этого, по видимому, никуда не дется. Это - ПЛАТА за бизнесовское "надо вчера"...
32. Alligator84 52 09.10.18 07:34 Сейчас в теме
(29)
И юзерам в зубы. Через пару не дней, часов косяки налицо.


Будет очень печально, когда встанет отгрузка со склада или еще какая-либо "процессно-значимая" фича.
Я был свидетелем разбора таких ситуаций у ген.дира, когда руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату и медленно намокали майки, а лица становились багрово-алыми.
Конечно же, это не норма такой разбор полетов - но повышать качество выпускаемых фич однозначно надо, моё ИМХО.
ivanov660; +1 Ответить
39. Арчибальд 2705 09.10.18 17:00 Сейчас в теме
(32)
руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату
Я про ИТ-фирмы не говорю. Три руководителя = перебор для любой другой фирмы.
Будет очень печально, когда встанет отгрузка со склада или еще какая-либо "процессно-значимая" фича.
Такое может быть только у менеджера. Руководители знают Козьму Пруткова: и при железных дорогах сохраняй двуколку. Внедрение новой фичи не может сопровождаться разрушением старых механизмов - ну, при нормальном руководстве, конечно.
41. Alligator84 52 09.10.18 17:32 Сейчас в теме
(39) Как раз таки, это не была ИТ организация. Было создано ИТ подразделение со своими руководителями по направлениям.
55. Арчибальд 2705 10.10.18 10:56 Сейчас в теме
(41)
Было создано ИТ подразделение со своими руководителями по направлениям.

Ужас какой. И сколько времени прошло от создания подразделения до обнаружения его неэффективности?
56. Alligator84 52 10.10.18 11:02 Сейчас в теме
(55) К сожалению или к счастью, я не участвовал в этом процессе, да и про эффективность никто выводы при мне не делал.
Уверен, что эффективности можно достичь в любой структуре, вопрос полномочий и знаний того, кто управлять будет.
59. Арчибальд 2705 10.10.18 22:26 Сейчас в теме
(56)Ну, как же?
Я был свидетелем разбора таких ситуаций у ген.дира, когда руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату и медленно намокали майки, а лица становились багрово-алыми.
61. Alligator84 52 11.10.18 08:17 Сейчас в теме
(59) Не участвовал в создании и не фиксировал его НЕ эффективность. По сути, это структура очень хорошо показывала количество возвратов на доработку, при этом не нервируя пользователя на продуктиве.
62. Арчибальд 2705 11.10.18 19:56 Сейчас в теме
(61) Понял. Структура показывает, не нервирует.... все по феншую. Кстати, китайцы, когда все по правилам, а толку нет, херят правила. Поэтому у них 7% роста ВВП, а у нас 0.
33. zqzq 17 09.10.18 14:15 Сейчас в теме
Тестирование, всё же, не единственный вариант повышения качества разработки. Есть и другие, более независимые от команды и др. внешних факторов и не влияющие на скорость разработки в худшую сторону.

Есть, например, внутренняя автоматизация. У нас работает база-центр обменов и обработка обновления рабочей базы нединамически одной кнопкой (инструменты моего изготовления с учетом специфики).

Также есть повышения качества самого кода. Я не про унылые стандарты с ИТС (но и не против них). Отличная книга "Совершенный код" Макконела. Или написание запросов (почти) без конструктора (консоль запросов Инструментов Разработчика помогает автодополнением текста). Или освоение СКД в конце-концов (меньше кода -- лучше его качество).

Как-то экспериментировал с TDD, но моё впечатление, что более высокоуровневые приемочные тесты типа BDD это проще и более "по-1Сному", чем на каждую тривиальную функцию лепить тест по канонам классического TDD. (Но в те времена 1С-BDD было неразвито и как-то забросил тему.)
34. Alligator84 52 09.10.18 14:20 Сейчас в теме
(33) как всё то, о чем Вы написали поможет проверить 159 фич, которые могут быть "затронуты" новым релизом и гарантировать работающий функционал утром при ночном обновлении продуктива?
35. zqzq 17 09.10.18 14:27 Сейчас в теме
(34) Очевидно, никак ;) Но это поможет создавать меньше косяков изначально...
36. Alligator84 52 09.10.18 14:35 Сейчас в теме
(35) Вы пишете об инструментах создания/генерации кода, но не о механизмах проверки методов/фич - согласитесь, разный контекст.
37. artbear 1084 09.10.18 15:35 Сейчас в теме
(33) Согласен с тем, что есть и другие способы повышения качества.

Лучше применять все варианты, причем системно, а не эпизодически.

Статический анализ кода, полная расширенная проверка, прогон через SonarBSL, дымовые тесты разных видов, продвинутые инструменты, отладка запросов, авторазвертывание, сервер непрерывной интеграции, сервер развертывания и т.п. и т.д.
38. Alligator84 52 09.10.18 15:46 Сейчас в теме
Ух куда нас занесло) следующая статья про новичка в DevOps...
40. herfis 261 09.10.18 17:00 Сейчас в теме
Некогда тесты писать, тут даже говнокодить не успеваешь, давай-давай :)
К сожалению, в большинстве случаев ситуация именно такая.
Серьезные подходы получается внедрять и они окупают себя только в серьезных продуктовых командах, которые востребованы в ограниченном количестве.
Где большие сложные продукты с большим количеством пользователей, поставленный цикл разработки и т.п. и т.д.
А не когда разработка идет в полтора лица, а цикл разработки разбит на случайные итерации от одного подзатыльника до другого с требованиями "на вчера".
ЧерныйКот; +1 1 Ответить
45. ImHunter 21 09.10.18 20:17 Сейчас в теме
(40) Есть такая ситуевина.
Тут нужно автоматизироваться. Это почти без вариантов.
Т.е., нужно иметь возможность - куда-то выкладывать тесты. На сетевой ресурс, на интранет-гит, на внешний гитлаб, еще куда-то.
И нужны постоянные автоматические прогоны выложенных тестов на тестовом контуре. Результаты - должны публиковаться где-то. И/или пусть приходят по эл.почте.
Тогда это будет хорошим стимулом писать тестируемый код и сами тесты.
Это я себя так подбадриваю;)
Нужно уже собраться и написать какую-то такую сборочно-тестовую линию.
Я, в свое время, пошел по альтернативной ветке - не по учениям Серебряной пули. Написал и почти не развиваю обертку Ванесса-Раннер/Деплойка для Jenkins для автоматизации развертывания.
Хех, нужно уже написать линию тестирования.
47. Alligator84 52 10.10.18 08:02 Сейчас в теме
(40)
Некогда тесты писать, тут даже говнокодить не успеваешь, давай-давай :)

Корень проблемы в том, что повышать свой профессиональный уровень хотят единицы, все остальные из "под палки".
Я приведу пример из своего управленческого опыта:
- объявил всем сотрудникам о том, что бюджет на обучение не ограничен (за это, конечно, особая благодарность моему руководителю, который "услашал" меня), выбирайте любые курсы - учитесь, в том числе с выездом в мск.
- только один сотрудник из 40 прошел обучение и сдал на спеца с первого разва в УЦ №1 за два года.
Вот так то!
49. sam441 10.10.18 10:02 Сейчас в теме
(47)
только один сотрудник

я знаю этого сотрудника)) респект за статью
Alligator84; +1 Ответить
51. genayo 10.10.18 10:17 Сейчас в теме
(47) Или у вас очень странные сотрудники, или вы что-то не договариваете по условиям обучения.
52. Alligator84 52 10.10.18 10:20 Сейчас в теме
(51)
Или у вас очень странные сотрудники

Сотрудники были одни из лучших)
(51)
или вы что-то не договариваете по условиям обучения

Никаких обременяющих условий быть не могло, в принципе, компания могла себе это позволить.
В долгую перспективу выигрывали все.
53. genayo 10.10.18 10:46 Сейчас в теме
(52) Тогда согласен, что 1С-ники в большинстве своём ленивые :))
54. Alligator84 52 10.10.18 10:48 Сейчас в теме
(53) Лень - это не всегда плохо, лень + задача в срок с заданным качеством = эффективность!
57. genayo 10.10.18 11:50 Сейчас в теме
(54) Тогда сотрудники правы, получается. Им не нужны были курсы, чтобы быть эффективными, только и всего.
58. Alligator84 52 10.10.18 11:52 Сейчас в теме
(57) в их матрице мышления - да!
50. Alligator84 52 10.10.18 10:15 Сейчас в теме
60. Fox-trot 90 10.10.18 22:58 Сейчас в теме
гиты, шмиты....
как-то договорился с коллегой, что будем родное хранилище использовать. ну хотя бы так
ок, говорит, погнали...
гнали мы не долго, до возвращения начальника из отпуска
такие дела
63. herfis 261 12.10.18 15:40 Сейчас в теме
Если на то пошло, то TDD своей основной и самой вкусной частью - про юнит-тестирование. А в 1С с юнитами несколько особая ситуация.
Половина настолько простые, что овчинка выделки не стоит, а половина настолько "завязанные", что тоже овчинка выделки не стоит (мокать устанет рука да и смысла особого нет).
Функциональные и интеграционные автоматические тесты - это да. Это реально полезно. Только классическое TDD не про них.
64. Alligator84 52 12.10.18 15:55 Сейчас в теме
(63)
а половина настолько "завязанные", что тоже овчинка выделки не стоит (мокать устанет рука да и смысла особого нет)

Макконелл, в том числе, писал о том, что код должен быть со "слабыми" связями.
Когда Вы изначально пишите тест, а после сам код, то это правило соблюдается как нельзя лучше.
Пока я вижу плюсы...наверняка, будут и сложности, но это скорее будет ограничением применимости технологии именно в 1С, но никак не посыл к отмене.
65. herfis 261 12.10.18 17:17 Сейчас в теме
(64) Удачи. Хотите попробовать фигней пострадать - ваше право.
А лично я бы сосредоточился не на эфемерном TDD в 1С, а хотя бы на простейших функциональных и интеграционных тестах.
Чтобы получать ответ на самые насущные вопросы:
- не сломался ли запуск 1С
- не сломалась ли работа форм
- не сломалась ли работа документов на тестовых наборах данных
Так даже до этого руки не доходят.
66. Alligator84 52 12.10.18 17:19 Сейчас в теме
(65) И Вам удачи, у каждого свой путь!
Ну и ждем от Вас статьи на описанные Вами темы.
67. herfis 261 12.10.18 17:31 Сейчас в теме
(66)
Ну и ждем от Вас статьи на описанные Вами темы.

Жаль вас разочаровывать, но вроде бы я не давал повода для такого рода чаяний.
68. spacecraft 12.10.18 17:58 Сейчас в теме
(64)
Пока я вижу плюсы...наверняка, будут и сложности, но это скорее будет ограничением применимости технологии именно в 1С, но никак не посыл к отмене.

Я бы акцент сделал на "ограничением применимости технологии именно в 1С".
ТДД был придуман на ООП. Именно там это работает так, как нужно.
Даже Серебряная Пуля пришла к тому, что чисто модульные тесты в 1С не панацея. И сместили разработку несколько в другое русло.
69. spacecraft 12.10.18 18:09 Сейчас в теме
(64)
Макконелл, в том числе, писал о том, что код должен быть со "слабыми" связями.

Вот когда в 1С будет возможно использование SOLID, DI, IOC без костылей, тогда и можно говорить о TDD.
Сам использовал TDD на ОПП. Реально стоящая вещь. Обеими руками за эту технологию. Но в реалиях 1С об этом можно только мечтать.
70. acsent 1077 15.10.18 17:05 Сейчас в теме
Сама методология ТДД - сначала тест, потом код не совсем подходит когда пишешь с 0.те "творишь".
Вот для исправления ошибок - вполне можно
71. spacecraft 15.10.18 17:20 Сейчас в теме
(70)
Сама методология ТДД - сначала тест, потом код не совсем подходит когда пишешь с 0.те "творишь".

Как раз наоборот. Именно когда с нуля. В любом случае, сразу с нуля писать код без предварительного обдумывания структуры и чернового плана, мягко говоря "код в никуда".
Именно TDD помогает сразу писать структурированный и покрытый тестами код. По другому просто сложно. И главное: код получается малосвязанный. TDD прямо навязывает использовать "включение" зависимостей.

Вот для исправления ошибок - вполне можно

Вот для исправления ошибок, это уже не TDD. И не каждый код можно "покрыть" модульными тестами. Да же не беру код завязанные на внешние факторы. Просто после "творишь" на это спагетти не всегда можно написать тест.
Fox-trot; +1 Ответить
72. acsent 1077 15.10.18 21:35 Сейчас в теме
(71) писать в стиле ТДД вполне можно не писав при этом сами тесты.
когда творишь процедуры могут по 100 раз меняться - это нужно 100 х 500 тестов переписывать
PS творишь - это НЕ то когда пишешь по ТЗ. дорбавьте на форму реквизит "А". при его изменении должен измениться реквизит "Б"
73. spacecraft 15.10.18 22:21 Сейчас в теме
(72)
писать в стиле ТДД вполне можно не писав при этом сами тесты.

Это как? Само название как бы говорит, что тесты вначале.

Если речь про попытку "писать в стиле ТДД" в 1С, то даже обсуждать это не буду. Уже говорил почему.

TDD это совсем не то, что вы себе представляете. Это нужно вникнуть в методологию. Научиться мыслить в нужном направлении.

Это как начать писать код под управляемые формы после обычных. Требуется перестраивать мышление, а не пытаться на УФ писать по привычке как на ОФ.
Чтобы не было недопонимания: это не прямая аналогия.
74. acsent 1077 16.10.18 10:46 Сейчас в теме
(73) Писать в стиле ТДД - писать код, который легко тестировать
75. spacecraft 16.10.18 11:00 Сейчас в теме
(74) это не TDD.
Вся прелесть TDD в том, что вначале пишется тест того, что должно получиться. Заметьте, не как, а что. Запускается тест. Если тест проходит, значит есть ошибка. Именно так. Ошибка!
Первый тест никак не должен проходить.
Если тест не прошел, то пишется простейшая реализация модуля. Ровно такая, чтобы тест прошел.
Дальше интересней. При необходимости пишется тест проверяющий пограничные значения. И самое главное. Делается рефакторинг того простейшего кода, который был написан только для прохождения теста. При каждом изменении кода прогоняется тест. Этим мы отслеживаем работоспособность кода.
Пример: Нужно создать метод деления чисел.
1. Пишем тест: Проверяем, что 6/2=3
2. Проверяем метод. Ошибка. Отлично.
3. Пишем код: Возврат 3. Да, в данном случае утрированно, но в общем смысле именно так в простейшем случае. Не пытаемся полностью написать сложный метод.
4. Проверяем. Тест проходит.
5. Пишем тесты на пограничные условия. Типа деления на 0. И другие выборочные значения.
6. Проверяем. Не все тесты проходят.
7. Изменяем код под новые тесты.
8. Тесты проходят.
9. При необходимости делаем рефакторинг. Цель: оптимизировать вычисление.
10. Прогоняем тесты. Если проходят, то готово. Иначе повторяем с п.7.
76. herfis 261 16.10.18 11:06 Сейчас в теме
(74) Не. TDD - это достаточно специфическая штука.
Просто его настолько часто поминают всуе, когда разговор заходит за юнит-тестирование, что люди которые не сильно в теме начинают их как синонимы использовать. И юнит-тесты и написание хорошего кода, в том числе легко тестируемого - это все и без TDD прекрасно себя чувствует.
77. acsent 1077 16.10.18 11:50 Сейчас в теме
Писать с стиле ТДД и использовать методику ТДД для разработки - это разные вещи
78. herfis 261 16.10.18 13:07 Сейчас в теме
(77) "Писать в стиле ТДД" - если при этом вы не пишите тестов ДО кода, то фраза будет некорректна.
Если вы пишите хороший тестируемый код и даже пишите потом отличные тесты на этот код - то так и говорите. Не нужно приговаривать про TDD - он никакого отношения к этому не имеет, вы только введете людей в заблуждение. Это вообще разные плоскости.
TDD - это всего лишь идеология использования тестов в качестве ТЗ. Формулируете требования, воплощаете их в тестах и только потом реализуете код, удовлетворяющий этим требованиям. Именно в таком порядке. Тесты могут быть говно, код может быть отстой, зато можно смело заявлять, что вы ведете разработку по TDD и это будет чистая правда.
79. acsent 1077 16.10.18 15:38 Сейчас в теме
(78) Что такое ТДД - это понятно, просто вопрос: реально ли кто-то использует ТДД для прототипирования системы?
80. spacecraft 16.10.18 15:56 Сейчас в теме
(79) Рекомендую почитать книгу Р. С. Мартина и М. Мартина «Принципы, паттерны и методики гибкой разработки на языке C#»
81. herfis 261 16.10.18 16:16 Сейчас в теме
(79) Апологеты утверждают что да - используют. Типа фишка даже не столько (или не только) в покрытии кода тестами как таковом, сколько в особом методе мышления и подходе к разработке. Который форсит думать о правильных вещах вовремя и из которого вытекает куча полезных плюшек.
Оставьте свое сообщение