Механизмы тестирования в 1С. Использование методики TDD (разработка через тестирование) в 1С

Публикация № 326820

Разработка - Практика программирования

Данная статья написана по материалам доклада, прочитанного автором на первой конференции инфостарта 2012 года. Она опубликована в журнале Инфостарта №1.

 

Основные этапы разработки в 1С

  • Проектирование
  • Кодирование
  • Тестирование
  • Отладка

Проектирование в 1С очень часто пропускается. Если оно и происходит, то только в достаточно небольшом объеме, и то только у серьезных команд. Чаще всего, оно происходит в уме (где-то,  как-то).

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

Дальше идет следующий этап – это этап тестирования. То есть, тестирование – это мы проверяем требования заказчика (требования, которые мы должны выполнить).

Дальше идет поиск ошибок, отладка.

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

Есть такой закон, который я, например, прочитал у Макконелла – Главный закон качества ПО:

Повышение качества программного обеспечения снижает затраты на разработку и сопровождение системы.

Что это означает? Это означает, что чем лучше у нас написана система, чем лучше она спроектирована, чем лучше обоснованы связи, тем легче мы сможем ее дорабатывать, исправлять и т.д.

Пример правильности этого закона: Отладка и исправление неверного кода занимает около 50 % времени. То есть – 50 % времени всей разработки мы тратим на поиск ошибок.

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

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

 

Методики разработки

  • Защитное программирование
  • Обзоры кода
  • Проектирование
  • Тестирование
  • Экстремальное программирование

Я лично пользуюсь всеми перечисленными методиками.

  1. Защитное программирование –  это методика, когда мы ведем разработку и само написание кода помогает нам не допускать ошибок. То есть, в этом случае мы что делаем? Мы проверяем данные.
    Элементарный пример – у нас есть какая-то функция, которая принимает входные параметры определенного типа, определенных значений. Мы можем в функции сделать предположение  (так называемый инвариант или утверждение) и проверить эти предположения. То есть, мы не пишем, как 1С привыкла: параметр и в комментариях пишем, что тип такой-то, значения такие-то, варианты  и так далее…  Мы можем прямо написать утверждение – вот этот параметр должен быть такого типа. Если это утверждение не выполняется, программа просто выдает исключение и останавливает свою работу, потому что это является ошибкой разработки.
  2. Следующая методика – это «Обзоры кода». То есть, мы можем читать чужой код. То есть, один кто-то написал код, мы можем попросить соседнего разработчика, руководителя посмотреть и проанализировать ошибки, которые были допущены в этом коде. Это методика очень эффективна.
    Я люблю читать чужой код, люблю свой код пересматривать. Таким образом находится достаточное число ошибок.
  3. Следующая методика - проектирование. Чем лучше мы построим программу, чем лучше продумаем связи, чем лучше продумаем архитектуру, интерфейсы взаимосвязей, тем лучше наша система будет работать, тем удобнее нам ее будет исправлять.
  4. Методика, которая известна лучше всех предыдущих – это тестирование. Фактически, каждый разработчик выполняет эту функцию, применяет методику тестирования. Но очень многие проверяют в уме. То есть этот код должен получить такие-то результаты… Мы проверяем какой-то один вариант, проверяем два варианта, проверяем три варианта…  А на самом деле в сложных системах вариантов очень много и их нужно проверять достаточно большое количество. И когда вариантов очень много для проверки, фактически получается, что они не проверяются все. У меня есть пример, есть система, идет цикл разработки, система отдается на проверку пользователю. У пользователя стоит тестирование – проверить 40 разных пунктов – релиз выпускается, например, раз в два месяца (или в месяц). Пользователь должен перед выпуском каждого релиза проверить 40 пунктов – это тяжело и он никогда практически не будет этого делать. Он будет помнить, что он это проверял в прошлый раз – и сегодня он этого делать не будет, потому что тогда на это придется потратить весь день. Как правило, отдельный тестировщик на проекте есть очень редко, обычно человек должен выполнить функцию тестировщика и выполнить свою основную функцию. В итоге функции тестировщика, как правило, пропускаются и тестирование не выполняется в полном объеме.
    Дальше я еще потом на тестировании остановлюсь…
  5. Следующая – очень эффективная методика – это методика экстремального программирования. Это методика свежая, буквально начала-середины 90-х годов. На западе очень сильно распространена, очень много информации по ней. У нас применяется не так много. Иногда эту методику называют «гибкие методики разработки», иногда – экстремальное программирование.

 

Экстремальное программирование

У него есть несколько принципов:

  • Единая команда
  • Совместное владение кодом системы
  • Обзоры кода и парное программирование
  • Разработка через  тестирование (TDD)
  • Функциональное тестирование
  • Рефакторинг
  • Простота
  • Короткие циклы
  • Непрерывная интеграция
  • Улучшение дизайна, постоянное планирование

Расскажем о них поподробнее:

  1. Первый принцип – это единая команда. Единая команда – это означает, то команда работает вместе. Каждый член команды осведомлен о целях проекта, о задачах, которые необходимо выполнить, как идет проект, на какой стадии он находится.
  2. Есть еще такое понятие в экстремальном программировании  – я его даже не стал тут выделять, потому что это достаточно сложно для понимания – есть такое понятие – «метафора». То есть, у проекта, который находится в экстремальном программировании, должна быть единая метафора, единое простое представление, что делает система. Эта метафора может не относиться к какой-нибудь конкретной задаче, ее можно именно представить в уме – команда просто должна представлять себе, что это такое – небольшим набором слов (одна-две фразы). Но эта метафора должна быть.
  3. Из единой команды есть следствие, что код, на котором пишется система – общий код не должен являться чьей-то собственностью. Код должен быть совместным. То есть – любой разработчик может исправить любое место кода. Это очень важный принцип и очень часто он нарушается. То есть – у нас пример – есть какой-то разработчик, который обладает большими знаниями, большими способностями, знает какую-то конкретную методику или знает предметную область, которую должен решить и он не пускает никого в свой код. Фактически для проекта это плохо.
    Этот разработчик владеет полностью своим кодом и проект полностью в этом месте может заморозиться. Он зависит только от этого разработчика. Для проекта это очень  вредно.
    Совместное владение кодом влечет за собой возможность гибко менять проект, возможность единого владения всеми членами команды знаниями о коде. В результате мы не зависим от конкретных людей (человек заболел, ушел, уволился) – у нас система проекта остается в работе и вся команда дальше работает вместе.
  4. Есть еще соответственно методика - парное программирование или обзоры кода. По парному программированию, это – фактически работают два пользователя, два разработчика. Один разработчик пишет непосредственно код, проектирует, второй сидит рядом и выдает ему комментарии, что ты здесь сделал неправильно, ты здесь сделал ошибку и т.д. Строго говоря: один пишет – один контролирует.
    Это единственная методика, которую я не применял, то есть у меня к ней подозрения – не могу ее рекомендовать, потому что не проверял.
    Обзоры кода, как я уже сказал – я применял – то есть, это очень полезная методика.
  5. Дальше – следующая методика, которая используется в экстремальном программировании – это разработка через тестирование (TDD). Смысл этой методики я раскрою дальше, расскажу пока что очень кратко.
    Сначала пишутся тесты. Потом пишется код под эти тесты. После того, как тесты проходят – код считается завершенным.
    Цикл:  тест – код – тестирование.
    Код никогда не пишется до тестов.
  6. Дальше – есть функциональное тестирование, иногда называется «Приемочные тесты». Это то тестирование, которое выполняет заказчик.
    Обязательно, как я уже говорил – единая команда, заказчик всегда участвует в команде. Он принимает участие во всех этапах проекта. Готовит сам тесты. То есть – заказчик обязательно должен участвовать – это тоже одно из требований экстремального программирования.
  7. Очень важный фактор экстремального программирования – это рефакторинг.
    Рефакторинг – это изменение кода (важное условие – изменение работающего кода).
    То есть, не добавление какого-либо функционала – только исправление работающего кода для того, чтобы увеличить его качество, упростить связи, интерфейсы и так далее.
  8. Также очень важный параметр экстремального программирования – это простота. Проект стремится быть максимально простым по дизайну, по реализации. Не придумывается никаких лишних дополнений/допущений. Проект работает «на сегодня». Он не работает на будущее – через 10 лет, через 5 лет. Он, как правило, работает на сегодня. То есть – у нас есть требования, мы, в общем-то, продумываем эти требования, думаем о масштабировании, об увеличении, но стараемся писать, стараемся выполнять проект только для текущих задач.
  9. Следующее понятие – это короткие циклы. То есть, итерации проекта несут очень маленький характер. Если один разработчик – 5-10 минут, написал тест, код, проверил – идем дальше.
    В результате коротких циклов у нас есть уверенность в том, что система работает и все тесты проходит. Но это – опять же, все основано на тестах.
  10. Есть еще такое понятие – непрерывная интеграция. Для  1С  это, в общем-то, не так часто используется, но – тем, кто работает в коллективной разработке, с хранилищем, это должно быть известно,  -  то есть, изменения в основное хранилище должны вноситься очень часто.
    Разработчик добавил какой-то функционал в свой небольшой участок, протестировал его и обязательно занес  в основной код.
    Не через месяц, не через неделю – а часто, раз в день (так называемые «ночные сборки»). То есть, в течение дня выполняется работа. Ночью происходит «ночная сборка». Это можно автоматическими средствами выполнять. Выполняются тесты – например, ночные тесты - полностью все тесты. Если система полностью прошла все тесты – значит, наутро мы признаем, что функционал у нас принимается – делаем новую сборку системы.
  11. Еще одно важное требование экстремального программирования – это улучшение дизайна.
    Всегда каждый разработчик думает о дизайне системы. Думает, как улучшить систему, как устранить дублирование, какие части кода не нужны в системе. Постоянно планирует. Заказчик в этом тоже непосредственно участвует, как я уже говорил.

Вернемся к тестированию. Будем говорить только о тестировании.

 

 

 

Виды тестирования

  • Модульное тестирование (юнит-тестирование)
  • Функциональное тестирование
  • Тестирование методом черного ящика и методом белого ящика
  • Нагрузочное тестирование
  • Тестирование разработчиком и специальными тестерами
  • Самый проблемный вид тестирования – тестирование пользовательского интерфейса

Теперь об этих видах тестирования подробнее:

  1. Самое основное, про которое я буду в дальнейшем рассказывать – это юнит-тестирование или так называемое модульное тестирование. То есть, это тестирование частей системы, компонентов, модулей. Это самое простое, что может делать разработчик – любой причем разработчик 1С – как один человек, так и команда. Это самое простое – здесь нет никаких дополнительных проблем. Все зависит от разработчика и от той системы тестирования, которую он использует.
  2. Дальше – есть такой термин – функциональное тестирование или приемочные тесты или – там несколько названий – это тесты всей системы в целом.
    То есть – смотря что мы разрабатываем – если мы пишем какой-то отчет, это может быть формирование отчета – какие данные из него получаем. Если это проект в целом – то это проверка всего пользовательского интерфейса.
  3. Есть тестирование методом белого и черного ящика.
    Методом черного ящика – это соответственно, мы ничего не знаем о системе, как она функционирует. Мы знаем только то, что подается на вход системы и то, что подается на выход системы. И можем проверить только эти соотношения. Это, как правило – тестируют специальные тестировщики. То есть, вот например, функциональное тестирование очень часто тестируют именно методом черного ящика.
    Есть метод белого ящика – то есть, мы опять же знаем, что у нас внутри, как организован проект, какие идут связи и можем более точно построить тесты, например, предположить, что на каких-то граничных условиях наши тесты могут падать.
  4. Следующий вид тестирования – это нагрузочное тестирование или стрессовое тестирование
    Это проверка на какие-то граничные факторы системы, например, на работу с очень большим количеством пользователей, или работу с условием – мало памяти, мало места на жестком диске и т.д.
  5. Также тестирование может выполняться разработчиком или специальными тестерами.
    Но в своей работе, как правило, я видел, что тестирований специальными тестерами выполняется либо мало, потому что средств тестирования очень мало, либо они очень дорогие.
    То есть, организацию тестирования специальными тестерами сделать довольно сложно. Тестирование разработчиком – это самое простое, потому что это может выполнить любой  1С-ник независимо от своего уровня.
  6. Самый проблемный вид тестирования – это тестирование пользовательского интерфейса. То есть, здесь очень сложно организовать, потому что, например, в 1С8 построено все на собственной оконной системе, значит, сторонние какие-то программы не могут получить информацию о том, что происходит в 1С.
    А в 1С до недавнего времени не было возможности обратиться и протестировать интерфейс.
    Но – есть уже система тестирования интерфейса в 8.3 и есть система, которая называется «Тест-Комплит», которая позволяет протестировать пользовательский интерфейс, но ее цена – 2500 долларов. Эта система позволяет тестировать любые приложения - .NET приложения, Web-приложения, 1С-приложения (в 7.7 – я лично проверял), но очень дорогое, конечно, лицензирование.

Сейчас немного коснусь существующих систем тестирования

 

 

 

Существующие системы тестирования

  1. Первое, с чем мы знакомы, когда говорим «Тестирование 1С» - это, конечно конфигурация «Сценарное тестирование» (входит в пакет 1С:КИП).
    Мое мнение вкратце – не пригодно оно к реальному использованию.
    Оно сделано больше для функционального тестирования и очень сильно зависит от изменений в программе.
    Если в форме добавился какой-то реквизит, Сценарное тестирование может вылетать, если в форме удалился какой-то реквизит – Сценарное тестирование может вылетать.
    Нет возможности исключить ошибки, прогнать все тесты за исключением ошибок. Если есть ошибка, тест остановится весь.
    Кроме этого, неприятным моментом является то, что конфигурация «Сценарное тестирование» не продается отдельно от пакета конфигураций «Корпоративный инструментальный пакет». А цена этого пакета очень велика.
    Хотя – лично мое мнение, что тестирование в 1С должно быть бесплатным.
  2. Есть очень хорошая подсистема (автор - Сергей Старых) – называется Подсистема «Инструменты разработчика».
    В этой подсистеме недавно появилось тестирование. Были введены начальные понятия тестирования – тестируются все формы и часть метаданных, то есть, тестируется открытие всех форм, которые есть в конфигурации, для документа тестируется проведение документа, запись документа, удаление документа и т.д.
    Самое интересное – тестируются события и интерактивные изменения форм.
    Например, тестируется ввод пользователем. Как будто пользователь вручную вносит данные. Это очень важно.
    Не в одной из систем, о которых я расскажу далее, нет тестирования этих интерактивных изменений. Например, там можно протестировать поиск по форме (по списку). То есть, как будто пользователь набирает символы, и подсистема это отрабатывает. Очень полезный инструмент.
  3. Еще есть некоторые публикации на сайте «Инфостарт».

3.1. Тестирование конфигураций на открытие форм – //infostart.ru/public/21489/ 

Одна из самых первых разработок, поэтому я о ней упомянул. 
Она неудобная и непродуманная на самом деле.

3.2. Есть модуль юнит-тестирования – //infostart.ru/public/22168/ (2015 - Автор удалил свою разработку, ссылка недействительна)


Это опять же, зачаточный такой модуль, просто пример того, как это можно организовать в 1С.

3.3. FuncTest.v8 - infostart.ru/public/19631/ (2015 - Автор удалил свою разработку, ссылка недействительна)


достаточно интересная, но почему-то автор ее удалил

3.4. Очень интересная разработка Тестирование (//infostart.ru/public/82718 ) Содержит:

  • Функциональное тестирование на обычных формах
  • Можно подключать различные алгоритмы
  • Можно тестировать запросы и т.д.
  • Недостатки: Нет управляемых форм и нет дальнейшего развития
  1. Дальше я укажу те системы, которые я сам реально использовал, с которых мое знакомство с системами тестирования для 1С началось:

4.1. Есть система юнит-тестирования для 1С 7.7 – это в свое время я и другие мои товарищи использовали при разработке ВК 1С++ и FormEx (www.1cpp.ru )

  • Эта система реально позволяет использовать разработку через тестирование (TDD) для 7.7
  • В свое время, благодаря использованию этой системы юнит-тестирования разработка ВК 1С++ стала намного более стабильной, и мы смогли получить стабильные, непадающие версии ВК

4.2. Есть также система Functest для 7.7 (автор Федор Езеев и я там тоже немножко дорабатывал в свое время) (http://1c.alterplast.ru/functest/ )

  • До сих пор тоже очень удобно использовать при разработке внешних отчетов/обработок
  • Проверка пользовательских данных. Например, проверка оборотно-сальдовой ведомости. Фиксируем некоторый набор данных – данные прошлого года, например. Если через полгода изменятся данные, значит, кто-то что-то изменил. Главное – нам удобно это отслеживать.

4.3. Собственная система Functest для 8.1/8.2 (//infostart.ru/public/15492 )

  • Я ее в 8.2 до сих пор успешно использую.
  • Недостатки:  немного устарела, нет управляемых форм

4.4. Предпоследняя система – это система юнит-тестирования SnowTest для 8.1/8.2  (www.1cpp.ru/forum/YaBB.pl?num=1267016427/0 ). Автор тоже Федор Езеев.

  • Ее как раз тоже можно использовать при разработке через тестирование (TDD) в 8.2

4.5. В новой платформе 8.3 наконец-то появилось более продвинутое тестирование, чем сценарное тестирование. Это система тестирования интерфейса  (http://v8.1c.ru/overview/Term_000000816.htm )

  • Шаги в нужном направлении
  • Только Управляемое приложение

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

 

То есть, толстый клиент или тонкий клиент менеджер тестирования взаимодействует (общается) с клиентом тестирования (толстым, тонким или Web-клиентом).
То есть – пишется тест на языке 1С. И заданные действия выполняются в клиенте тестирования.

 

Пример вызова приложения-теста

 

 

 

 

На данном скриншоте красная стрелка как раз показывает – есть вариант вызова записи действий пользователя, то есть в 8.3 можно использовать следующую схему работы:

  • Пользователь, который знает систему или разработчик может выполнить самостоятельно необходимые действия и записать эту последовательность действий в специальный файл, чтобы в дальнейшем производить этот файл уже в системе тестирования.
  • Один минус – пока 1С сделала только надстройку над платформой для записи этого XML файла.
    Среды тестирования пока что нет. То есть те результаты, которые мы можем получить, никоим образом системой 1с не обрабатываются, не анализируются.
  • Значит, мы должны написать код для системы тестирования сами
    Возможно, 1С сделает на следующем этапе свою систему тестирования, возможно, она переработает сценарное тестирование. Пока неизвестно. 1С молчит по этому поводу.

 

Рекомендуемая система для тестирования в 1С

(я фактически ее product-owner и один из авторов) - 

https://github.com/xDrivenDevelopment/xUnitFor1C/wiki (2012-2015 гг.)

В ней огромное количество возможностей, поддержка от 8.2.13 - до 8.3.5.ХХХ, запуск из командной строки, работа с build-серверами, есть хорошая документация, есть много примеров и тестов, есть видеотренинги и видео-примеры.

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

Система активно развивается как после первой конференции Инфостарт-2012

 

 

Защитное программирование

Защитное программирование – очень важный этап применения методики тестирования

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

Использование инвариантов/утверждений

  • Утверждения (assertion) – это код (метод или макрос), с помощью которого проверяется правильность заданного условия. В случае, если условие не выполняется, просто выбрасывается исключение – программа прекращает свою работу
  • Утверждения можно использовать только для проверки инвариантов, то есть постоянных условий – событий, которые никогда не должны произойти(считаются недействительными)
    • Пример вызова:
                     C++        assert (value !=0);
                     1C           артТесты. ПроверитьЗаполненность (парамКонтрагент, «Метод1::Не задан контрагент»);
    • В 1С в связи с тем, что нельзя получить контекст выполнения, приходится делать более сложный код – поэтому здесь утверждение принимает два параметра – первый параметр - это данные, которые нужно проверить, а второй параметр – это сообщение для анализа.
    • Главная задача утвержденийвыявить противоречивые допущения, некорректные значения и условия в ходе разработки программы
    • Утверждение должно останавливать программу. Это – самое главное. Никаких проверок, никаких обработчиков – только останавливать – вызываем метод «ВызватьИсключение».

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

Потому что иногда начинают использовать утверждения для передачи данных во внешнюю систему – это неправильно. Это уже не утверждение.

Я использую утверждения для разных случаев – у меня есть функция, например, в которой я знаю, что должен быть передан параметр, например СправочникСсылка.Номенклатура. Я так и пишу в коде:
                 Тесты.ПроверитьТип(Параметр, СправочникСсылка.Номенклатура)

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

Теперь – самое интересное: Тестирование разработчиком и разработка через тестирование. 

 

 

Тестирование разработчиком

Это та методика, которая должна использоваться любым разработчиком, если он хочет быть квалифицированным и получить максимальную скорость.

  • Затруднение у разработчиков (Цель тестирования отлична от других этапов разработки, Тестирование требует поиска ошибок в своем коде)
    Тестирование разработчиком вызывает затруднения, потому что цель тестирования отлична от цели разработки. То есть от разработки мы хотим получить правильный код, который правильно работает, получает верные результаты, содержит минимум ошибок и т.д. А в тестировании мы должны найти ошибки, наоборот. Иногда бывает это трудно. Разработчику бывает лень искать ошибки. Разработчик не понимает, что ошибки нужно искать и т.д.
  • Тестирование никогда не доказывает отсутствия ошибок.
    Но наличие тестов – это лучше, чем отсутствие тестов.

Что еще можно сказать об основных требованиях к тестированию:

Два главных требования тестирования:

  • Тестирование должно быть автоматизированным. А еще лучше – автоматическим 100%. Если тестирование не будет автоматизированным, его никто никогда выполнять не будет.
  • Тестирование должно быть быстрым.
     Если тесты будут выполняться медленно, их опять же никто не будет делать. Это все из опыта. 

Разработка через тестирование (TDD)

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

Результаты использования TDD

  • Быстрое нахождение ошибок и исправление ошибок
    В результате того, что мы используем тесты до разработки, мы быстро находим ошибки. Потому что пишется тест – потом небольшой кусок кода  - проверяется.
    Если тест упал – значит, вот у нас ошибка – в этом коде из 15-20 строк, и мы легко ее находим – на надо искать несколько часов в модуле из 20 экранов.
  • Отладка становится очень простой либо вообще не используется
    Я отладку использую очень редко. Потому что у меня все в тестах, как правило. В крайнем случае я пишу отладочные сообщения. Это более эффективно, чем ходить по коду, искать ошибки и т.д.
  • Уверенность в качестве ПО
    У того, кто применяет методику TDD, появляется уверенность в качестве ПО. Он видит, что система работает. Видит, как у него проходят тесты. У него появляется психологическая уверенность.
  • Простота доработки/рефакторинга
    Соответственно, поскольку у нас есть тесты – нам легко дорабатывать свою систему. Мы легко можем вносить изменения согласно требованиям заказчика и т.д.
  • Выбор проектных решений, например, интерфейсов взаимодействий и дизайна программы.
    Тестирование позволяет нам также заранее принимать проектные решения, т.е. интерфейсы, связи различных модулей, дизайн программ. Например, я вот работаю так – у меня есть задача сделать какую-то выгрузку. Я сначала делаю тесты, продумываю эту выгрузку. Когда мы пишем тесты, мы фактически продумываем дизайн программы. То есть я не рисую ничего в формах – все делается в модуле. Продумываю и только потом, когда моя программа проходит все тесты, которые я сам для себя определил, только после этого я рисую форму, в которой использую только нужные мне данные, которые нашел в результате тестов. То есть, в тестах у меня задан дизайн программы – это очень важно и это на самом деле удобно.
  • Разработка через тесты позволяет нам создать слабосвязанные модули.
    Когда мы пишем тест, если модули очень сильно связаны между собой, очень сложно написать хороший тест. Приходится городить неизвестно что. В результате тест не проходит, потому что у нас есть много связей. Приходится облегчать эти связи, т.е. переписывать код, переписывать тест. Зато в результате мы получаем слабосвязанную программу. И это правильно.
  • Еще один важный фактор, про который забывают – это создание документации.
    Очень часто у нас документация не связана с программой, т.е. происходит изменение в программе, документация, как правило, отстает от программы. А тесты всегда соответствуют программе. То есть – тесты выступают как всегда актуальная и доступная документация. То есть, если я возвращаюсь через полгода к проекту, который я выполнил на тестах, я первым делом смотрю в тесты и вижу, как все сделано. Если мне нужно доработать, я уже дорабатываю в соответствии с тестами.

Здесь указаны основные принципы, как надо выполнять разработку через тестирование (TDD).

Принципы (правила) разработки через тестирование

  • Основные принципы:
    • Не пишите код, пока не будет написан автономный тест, который не проходит
    • Не пишите тест в объеме большем, чем нужно для отказа
    • Не пишите код больше, чем необходимо для прохождения теста
    • Устраняйте дублирование
    • Используйте утверждения для проверки теста
    • Используйте автоматизированную среду запуска тестов
    • Запускайте тесты часто
    • В случае успеха нужна простая «зеленая» полоса. Иногда начинающие пишут много различных сообщений – это путает.
    • Подробные сообщения и «красная» полоса нужны только при отказе теста (для неверных тестов)

Все просто:

  1. 1.       Пишем тест, только тест, не пишем код. Причем только в том объеме, который нужен для отказа. Потом пишем код, но тоже только в том объеме, который нужен для теста.
  2. Последний принцип, про который иногда забывают – это устранение дублирования. То есть, в тесте и в коде не должны быть использованы одинаковые механизмы.
  3. Еще одно требование, которое я предлагаю использовать всем – это использование утверждений. Просто пишем, если тест должен проверять какую-то функцию, которая должна быть выполнена и возвращать какое-то значение, мы должны проверить это значение и все. Больше ничего нам не нужно.
    Просто пишем:
                                   Тесты.ПроверитьИстину(Условие)
  4. Как я уже говорил, тесты должны запускаться автоматически, поэтому должна быть какая-то среда. Тесты не должны запускаться вручную.
  5. Тесты должны запускаться часто. Если они не будут запускаться часто, мы напишем очень много кода. Напишем много кода – будет много ошибок.

Здесь у меня представлен цикл тестирования. Он очень простой:

TDD - цикл тестирования/кодирования

  • Пишем тест. Компилируем. В 1С под компиляцией понимается успешное прохождение проверки синтаксиса.
  • Запускаем тест. Убеждаемся, что он не проходит в режиме выполнения.
  • Пишем код в том объеме, который нужен для успешного срабатывания теста в режиме выполнения.
  • Запускаем тест и убеждаемся, что он корректно отработал
  • Обязательно выполняем рефакторинг  для «чистоты» кода, устраняем дублирования. Исправляем свой тест, чтобы он стал проще, легче. Исправляем свой код.
  • Повторяем последовательность сначала
  • Главное - использовать короткие циклы в разработке, чтобы поиск ошибок был наиболее упрощенным

TDD – принципы написания тестов

  • Тест должен решать одну задачу
  • Тест должен быть изолированным от других тестов
  • Тест должен быть относительно быстрым
    • Если тестов много и они работают долго, можно организовать ночную проверку всех тестов. Но это тоже неправильно, потому что проверяться должны все тесты.
    • Не пишем другой код, пока есть отказной тест
      • Иногда приходится пропускать отказные тесты
      • Тест должен подчиняться тем же правилам, что и код
        • Методики разработки
        • Чистый код и т.п.
        • В конце рабочего дня лучше оставить неработающий тест. Это позволит быстро войти в работу на следующий день. Не надо вспоминать, что делали накануне.

Выводы:

  • Для построения качественного ПО нужно использовать различные методики, а также комбинации различных методик
  • Используйте утверждения для повышения качества кода
  • Использование тестирования снижает затраты на разработку и сопровождение
  • Тестирование не гарантирует нахождение всех ошибок
  • TDD и тестирование повышают надежность ПО и качество системы
  • Работа разработчика становится более эффективной
  • Работа в режиме TDD приносит больше положительных эмоций
  • Вход в TDD не так сложен, как кажется тем, кто не знаком с TDD
  •  

Литература

  • С.Макконнел. Совершенный код
  • К.Бек. Экстремальное программирование
  • К.Бек. Экстремальное программирование: разработка через тестирование
  • М.Фаулер. Рефакторинг - улучшение существующего кода
  • Р.С.Мартин, М.Мартин. Принципы, паттерны и методики гибкой разработки на языке C#
  • К.Ауэр, Р.Миллер. Экстремальное программирование. Постановка процесса с первых шагов и до победного конца.
  • Р.С.Мартин. Чистый код

*****************

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

Специальные предложения

Лучшие комментарии
50. artbear 1180 07.10.16 20:40 Сейчас в теме
(49) Можешь писать здесь.
Можешь создавать issue на проекте, как ты сегодня и сделал.
Можешь писать в официальном чате https://gitter.im/xDrivenDevelopment/xUnitFor1C

2 последних варианта предпочтительнее.
Остальные комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. zorka-gold 09.02.15 14:16 Сейчас в теме
Много битых (не рабочих) ссылок !
Andris_infostart; +1 1 Ответить
2. artbear 1180 09.02.15 16:13 Сейчас в теме
(1) Ага, есть такое, все-таки выступление двухлетней давности.
Ссылки поправлю в ближайшее время.
3. artbear 1180 09.02.15 16:27 Сейчас в теме
(1) Исправил ссылки
Также добавил абзац
Рекомендуемая система для тестирования в 1С (я фактически ее product-owner и один из авторов) - https://github.com/xDrivenDevelopment/xUnitFor1C/wiki (2012-2015 гг.)
В ней огромное количество возможностей, поддержка от 8.2.13 - до 8.3.5.ХХХ, запуск из командной строки, работа с build-серверами, есть хорошая документация, есть много примеров и тестов, есть видеотренинги и видео-примеры.

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

Система активно развивается как раз после той самой, первой конференции Инфостарт-2012
4. awk 714 09.02.15 19:04 Сейчас в теме
Есть метод белого ящика – то есть, мы опять же знаем, что у нас внутри, как организован проект, какие идут связи и можем более точно построить тесты, например, предположить, что на каких-то граничных условиях наши тесты могут падать.
Специально обученные отделы тестирования, крайне не любят данный метод. Говорят, что он только сбивает.
8. artbear 1180 10.02.15 13:32 Сейчас в теме
(4) Белый ящик не всегда плох, как раз на знании особенностей реализации можно доп.тесты написать, которые помогут.
Черный ящик плох тем, что внутренностей не знаем, и не знаем подводных камней.
19. awk 714 16.02.15 23:06 Сейчас в теме
(8) тестировщику и не надо знать. Программисту - наверное надо.
21. artbear 1180 16.02.15 23:40 Сейчас в теме
(19) Есть разные мнения по поводу белого ящика, например, на Википедии есть информация об этом.
я уже отметил, что можно очень полезные доп.тесты сделать.
я лично обе методики юзаю при тестировании.
5. baloo 09.02.15 19:30 Сейчас в теме
В профессии уже 10 лет. 7.7-8.0-8.1-8.2-УТ-БП-УПП-итд-итп. Где-то полгода назад начал на досуге изучать веб-разработку, RoR, через него и вкусил TDD. Сильно заинтересовало, стал изучать литературу, пробовать применять к 1С. Сказать, что это изменило мой стиль разработки - не сказать ничего, это буквально перевернуло устоявшийся и "закостеневший" за годы процесс. Натыкался до НГ на упомянутый проект на гитхабе, разбирался, хотел присоединиться к разработке, но потом НГ, отчетность, дела, обучение, как обычно, короче, толком в курс не вошёл. В статье упомянуто про "видеотренинги и видео-примеры", где их можно посмотреть, киньте ссылкой плз.
pt_olga; slazzy; lustin; +3 Ответить
6. artbear 1180 09.02.15 23:45 Сейчас в теме
9. slazzy 39 10.02.15 15:12 Сейчас в теме
(6), Можно позадавать Вам пару вопросов по ходу обдумывания материала? :)

Например про Защитное программирование. По сути чем это отличается от простых проверок в начале функции? В 1С это является стандартом, мы вызываем функцию и проверяем параметры. Если параметры какие-то не такие, то чаще всего принято возвращать какое-то значение из функции и сообщать пользователю о неверных данных.

В чем критическая для разработки разница между accert и простой проверкой, которая в общем-то почти всегда используется в 1С. Если она не используется, то всё печально :)

Так же стоит упомянуть, что в БСП на текущий момент введен аналог функции accert, а именно
ОбщегоНазначенияКлиентСервер.Проверить И
ОбщегоНазначенияКлиентСервер.ПроверитьПараметр
Которые в самой БСП как раз как типичный accert из С++ и используются.


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


К тому же судя по-всему к 1С это вообще слабо применимо. Это в СИ какой-нибудь кусок памяти видимо может быть изменен другой программой и произойдет какая-нибудь непредвиденная ошибка. В 1С же практически существует конечный пул ошибок и почти всегда их можно предусмотреть и проверить. По сути в 1С и так предостаточно проверок и способов сделать эти проверки, да и сам язык довольно хорошо от них защищает.
10. artbear 1180 10.02.15 18:16 Сейчас в теме
(9) Механизм утверждений/assert-ов (не accert) предназначен именно для подтверждения контракта функции/процедуры и отличается от стандартных проверок параметров тем, что не возвращает некое значение в вызывающую функцию, а сразу выбрасывает исключение, прерывая выполнение кода!!
Это важный момент.
Фактически утверждение говорит о том, что заданы жесткое условие/состояние (инвариант), которому должны удовлетворять функция/процедура.
Здесь неважно, какое условие/контракт проверяется.
Например, можно проверять тип входного параметра, его значения и т.п.

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

По поводу скорости работы:
1. не допускайте преждевременной оптимизации. Как и в других языках, в 1С профайлер - главное мерило производительности, а не личные впечатления :)
2. как правило, проверки не бывают слишком сложными.
38. zqzq 21 25.03.15 16:30 Сейчас в теме
(6) посмотрел видео про змейку и прочее, очень познавательно, но... как-то от обычных 1С-ных задач далеко. В результате так и не очень понятно, как применять это TDD(Бека тоже почитал, но он работу с БД не любит и примеры с ООП не всегда гладко на 1С ложатся). В идеале нужно что-нибудь вроде примера решения задачи с 1С-ного билета по специалисту через тестирование.
40. artbear 1180 25.03.15 16:58 Сейчас в теме
(38) Пример со змейкой дает возможность просто и в игровой форме показать самые базовые приемы работы через ТДД.
У нас на подготовку змейки ушел не один день.
По реальным примерам:
если делать сложную разработку, слишком много времени это займет. а реальной пользы будет мало
Для начинающих сразу не нужно пытаться делать большую разработку с помощью тестов.
я предпочитаю двигаться по шагам, от деталей к общему.

Предложи свою задачу (пусть даже из 1С-билета). Совместно выполним ее анализ и совместно решим, что нужно тестировать автоматическими тестами, а что можно и вручную протестировать.

ОФФ. что-то Инфостарт совсем перестал информировать о новых сообщениях в моей же ветке :(
42. zqzq 21 26.03.15 09:02 Сейчас в теме
(40) на сайте 1с есть пример билета и каркасная конфигурация:
http://www.1c.ru/rus/partners/training/questions.htm
Можно взять первую задачу - оперативный учет. На экзамене на неё отводится примерно 60-90 минут. По-моему, она сильно ближе к реальным 1с-овским задачам, чем змейка, а вот как подступиться с помощью 1с-ТДД непонятно (действительно, может не 1 день занять, особенно с непривычки).
lenna1c; Quasar; Mos; +3 Ответить
7. lustin 10.02.15 06:51 Сейчас в теме
(5) baloo, вот за RoR отдельное спасибо - мы в процессе работы очень много вдохновения именно оттуда черпаем. И да - "мозг меняется".
11. sergei2k 10.02.15 19:08 Сейчас в теме
Конфигурация "Сценарное тестирование" поддерживает создание и выполнение тестов с использованием нового механизма платформы.
Но, сам механизм работает с ошибками (например, не записывает выбор панели функций раздела), и очень последовательность действий пользователя при записи сценария должна быть очень продуманной.
12. artbear 1180 10.02.15 19:35 Сейчас в теме
(11) Напоминаю, что это выступление 2012 года.
Тогда еще не было продукта сценарное тестирование для упр.приложения.
Согласен, что есть много сложностей при разработке таких тестов.
Например, ребята недавно нарвались на вылет 1С при попытке записи действий пользователя, если не была открыта ни одна форма.
несколько последних платформ 8.3.5 тупо падают.
стоит только открыть какую-то форму, а уж потом запустить запись, 1С нормально работает.
В общем, проблем масса.

Когда я осенью 2012 года был на партнерской конференции в Москве, в Космосе, специально подходил к разработчикам сценарного тестирования.
Они показывали как раз сценарное тестирования для упр.приложений, внутреннюю альфа-версию
Они мне сообщили, что на тот момент им неизвестно о тестировании продуктов упр.приложения (УТ 11, УНФ и др.) средствами автотестирования 8.3 :(
13. so-quest 131 11.02.15 10:59 Сейчас в теме
http://infostart.ru/public/22168/ ничего интересного из себя не представляет.

https://github.com/wwall/xUnitFor1C - тут добавлена поддержка проверки равенства структур. Может кому потребуется
14. artbear 1180 11.02.15 11:58 Сейчас в теме
(13) ты бы это как-нибудь документировал для понимания сторонними разработчиками.
А я бы тогда подумал о включении в основной xUnitFor1C :)
15. AlexSunS 15.02.15 17:34 Сейчас в теме
Как много веяний "новых" на ИС.
16. artbear 1180 16.02.15 01:02 Сейчас в теме
В Вики xUnitFor1C я документировал пример готового теста проверки отчета на СКД.
В тесте сначала создаются тестовые данные в базе, затем выполняется отчет на СКД, получается сводная таблица.
Эта таблица сверяется с эталоном.
JohnyDeath; +1 Ответить
17. minimajack 62 16.02.15 20:13 Сейчас в теме
(16) лишнее
юТест.ПроверитьБольше(ТестовыеДанные.Количество(), 0, "Ожидали, что загрузка макета загрузит данные больше 0");

вы же не юнит-тестирвание проверяете
18. pumbaE 633 16.02.15 20:31 Сейчас в теме
(17) 1с и чистый юнит-тест не совсем совместимы.
22. minimajack 62 17.02.15 08:02 Сейчас в теме
(18) pumbaE, (20)
имхо:
я к тому что "ПроверитьБольше" - это "от черта".
либо равенство количеству строк (количество = 5), либо равенство на булево ( количество > 0 )...
само по себе "больше" не помогает в тестировании, а наоборот помогает скрыть ошибки, т.к. проще написать больше 0 и забить
23. artbear 1180 17.02.15 19:32 Сейчас в теме
(22) ты прав, а мы внимания не обратили.
ПроверитьБольше здесь от "лукавого"
В Вики поправил, вообще удалив эту ненужную строку.
Спасибо!
24. pumbaE 633 18.02.15 09:12 Сейчас в теме
(22) minimajack, не соглашусь. Не в данном случаи, а в общем. ПроверитьБольше дает большее представление об ошибке чем "проверить(Количичество()>0) ", сразу видно что передано, параметр 1=0, параметр2(проверки) = 0 и уже в пояснении достаточно написать просто "ТЧ Товары.Количество()". В случаи же проверки истины, нам в пояснении надо писать "ТЧ Товары.Количество() = 0" и т.д., повторять тот же код, который мы пытались проверить.
25. artbear 1180 18.02.15 10:14 Сейчас в теме
(24) Женя, я лично считал, что в (22) говорится о ПроверитьНеРавенство(0, Таб.Количество()) или ПроверитьРавенство(5, Таб.Количество())
ПроверитьИстина(Таб.Количество() > 0) или ПроверитьИстина(Таб.Количество() = 5) явно плохо.
26. minimajack 62 18.02.15 12:24 Сейчас в теме
(24) pumbaE, по идее в тестах мы заранее знаем точное значение ожидаемого результата, и именно это значение надо использовать как написано в 25, если это невозможно использовать ( а это очень и очень маловероятно...по крайней мере в 1С8 без ВК и внешних сервисов) - использовать ПроверитьИстина(Таб.Количество() > 5) с описанием ошибки вручную - вплоть до ссылки на описание почему именно это значение.
Пример:
один и тот же набор данных используется при тестировании двух отчетов. Изменяют первый отчет(вывод дополнительных данных, новый тип операции и т.п.) -> меняют исходные данные (тестовый файл) -> меняют тест по первому отчету -> все ок; при этом второй отчет на ошибке ПроверитьБольше 0 все также будет проходить, но не факт что результат отчета будет идентичный. Если бы стояло ПроверитьРавенство(5, Таб.Количество()) - ошибка сразу стала бы известна - именно на этапе загрузки данных, а не по факту. То есть найти ошибку будет проще. И именно поэтому, я написал "помогает скрыть ошибки".
ПроверитьНеРавенство(0, Таб.Количество()) - аналогично скроет ошибку.
Использовать скрытое сравнение как ПроверитьИстина(Таб.Количество() = 5) - тоже плохо, как минимум тем что используется не по назначению и неудобно для рефакторинга.
ИМХО оптимальный ПроверитьРавенство(5, Таб.Количество()) - дает наиболее точный результат
В общем все это мое личное мнение. Я никого не принуждаю писать код именно так, просто исходя из своего опыта даю рекомендации.
27. artbear 1180 18.02.15 15:24 Сейчас в теме
(26) Да, согласен, что ПроверитьРавенство(5, Таб.Количество()) наиболее оптимально.
пара уточнений:
  • лучше писать ПроверитьРавенство(5, Таб.Количество(), "Таб.Количество()") или ПроверитьРавенство(5, Таб.Количество(), "количество созданных объектов")
  • ИМХО лучше вообще исключить эту проверку, как я сделал в Вики, т.к. в данном случае утверждение проверяет создание тест.данных, т.е. функционал, который вторичен для данной задачи. для этой задачи важно проверить именно соответствие результата отчета эталону, а не создание данных.
20. artbear 1180 16.02.15 23:38 Сейчас в теме
(17) Человек, который писал этот тест, еще не очень доверял методу юТест.СоздатьДанныеПоТабличномуДокументу :)
Поэтому и вставил подобную проверку для гарантии правильности теста.
А этот метод, как и многие в xUnitFor1C, либо работает и возвращает данные при правильном макете, либо падает с исключением, если макет неверен.

Как уже отмечено в (18), в 1С очень зыбкая граница между юнит-тестами и приемочными тестами.
Я лично давно уже не говорю "юнит-тесты" в 1С, а упоминаю именно тесты.
28. eugeniezheludkov 32 06.03.15 07:06 Сейчас в теме
Воу, хорошая статья , видимо ранее плохо искал раз не натыкался на неё. довольно хорошо и понятно разжевано именно как это реализовать на 1С. на хЮнит1С стал по другому смотреть! с удивлением для себя обнаружил там вики :). еще заинтересовала подсистема (автор - Сергей Старых) – называется Подсистема «Инструменты разработчика».
Тему в закладки, буду пытаться поднять её у себя (сейчас тестированием реальные люди занимаются).. если получится то отпишусь как и что вышло. ранее не находил дельной инфы и считал проект "костылем", приношу извинения.
яб еще добавил "статический анализ кода" на каком - нибудь этапе после код-ревью , т.е когда анализируется структура кода на возможные ошибки и даже неоптимальные участки кода (по шаблонам) во всяком случае для себя я простенький написал: ни одна типовая конфа не проходит 2 шаблона: "неиспользуемые(забытые переменные)","Запросы в циклах" на УПП к примеру это более 7000 таких неоптимальных участка. (выкладывал тут)
29. pumbaE 633 06.03.15 10:57 Сейчас в теме
(28) eugeniezheludkov, автоматизированя проверка конфигураций. Там есть попытка статистического анализа кода, но у меня терпения не хватает каждый раз ее проходить, видно в 1с та-же проблема.
p.s.: когда 90% кода типового, то к сожалению не всегда есть желание посмотреть на чужие ошибки, которые вряд-ли будешь исправлять или будут исправляться.
31. eugeniezheludkov 32 07.03.15 06:36 Сейчас в теме
(29) pumbaE, у меня анализ кода идет в ручном режиме. Внешняя обработка натравливается на выгруженные исходные коды всей конфы (шаблоны-регулярка) при этом чтоб отделить типовые объекты от своих, у нас правило: свои объекты имеют префикс. Проверяются объекты имеющие лишь этот префикс , результат выгружается в эксель, если исходники выгружались бы автоматом+гит+сервер сборок то впринципе эти шаблоны-регулярки могу легко перенеси в шарп, скорость проверки возрастет в разы
32. artbear 1180 07.03.15 11:28 Сейчас в теме
(31) Поделись кодом подобной проверки, очень интересно.
33. artbear 1180 07.03.15 11:32 Сейчас в теме
(32) Ага, увидел. Посмотрю, как сделано.
35. eugeniezheludkov 32 10.03.15 01:32 Сейчас в теме
(33) если что , тут последние коммиты , и сильно не пинайте за мои антипаттерны :( писал на коленке перед НГ
34. artbear 1180 07.03.15 11:33 Сейчас в теме
(31) А в чем проблема с реализацией автовыгрузки конфы на тексты? у нас давно реализовано - проект v83unpack
30. artbear 1180 06.03.15 14:17 Сейчас в теме
(28) (29) Да, пока только АПК остается.
Мы работаем над верификацией программ разными способами - синтакс-проверки, кросс-тестирование, автотесты, покрытие кода, код-ревью, АПК.
Минусы АПК (помимо скорости), о которых я говорил на общей стойке БСП/АПК на недавнем партнерском семинаре 1С - вся автоматизация внутри АПК, нет внешнего управления и возможности получения результатов проверки извне.
Мы пользуемся билд-серверами, они отлично себя показывают, и у меня в планах заставить АПК выполнять автопроверки именно через билд-серверы.
36. baloo 23.03.15 13:24 Сейчас в теме
По поводу проверки "Запросы в циклах" - у вас анализируется вызов в цикле процедур/функций, внутри которых совершается запрос? Кроме того, было бы здорово анализировать не только наличие явного исполнения запроса через запрос на встроенном языке запросов, но и обращение к реквизитам переменных ссылочного типа, что, по сути, влечет за собой неявное выполнение запроса к БД.
ПС обработку не видел, нисколько не критика - чисто размышления по улучшению :)
37. eugeniezheludkov 32 24.03.15 04:05 Сейчас в теме
(36) baloo, естественно анализируется вызов процедур и функций и неявные запросы (типа .НайтиПоКоду()) и отсекаются закомментированные вызовы, и детектируется вызов запросов в рекурсивных функциях https://github.com/znsoft/external1CProgs/blob/master/src/СтатическийАнализ­Кода1с/Form/Форма/module тут можете глянуть исходный код модуля,
todo(если появится время):
-анализ вызываемых функций в другом модуле (к примеру вызов через точку от другого объекта) сейчас такая функция не проверяется :( можно реализовать если просто строить таблицу вызовов функций первым проходом и анализ вызовов вторым проходом
-анализировать обращение к реквизитам переменных ссылочного типа (чет я про них и забыл то сам сколько раз по молодости обжигался :) спасибо за подсказку)
-убрать проверку неиспользуемых переменных т.к такая проверка есть в конфигураторе :)

сейчас времени не очень много (много ТЗ в очереди), все мечтаю рефакторить обработку и вообще переделать на шарп (мой фаворит) или на java для будущих версий 1С :)
39. artbear 1180 25.03.15 16:45 Сейчас в теме
--
>http://forum.infostart.ru/forum24/topic123336/message1323894/#message1323894 >
> 22. magnetto72 24.03.2015 08:06
Я не могу понять как создать/зафиксировать эталон движений, где он должен сохраниться.
При тестировании отчета формирую его, создаю макет "Эталон", копирую в него табличный документ, получаю эталон с правильным результатами.
В "1С:Сценарное тестирование" для этого есть специальное действие "Сравнить движение документа с эталоном", которое снимает "слепок" с эталонной базы, сохраняет все значения в сценарий и затем при прогоне сверяет с тем, что получилось.

А как зафиксировать эталон для движений в xUnitFor1C?
---
Ответ: если мы говорим про отчет, то можно получить эталон прямо по отчету. Пример такого теста: Проверить отчет на соответствие эталону (исходный код модуля обработки) - с сайта xUnitFor1C
41. artbear 1180 25.03.15 19:42 Сейчас в теме
В дополнение к (39) см. (16)
Продублирую:
В Вики xUnitFor1C я документировал пример готового теста проверки отчета на СКД (со скриншотами и готовым кодом).
В тесте сначала создаются тестовые данные в базе, затем выполняется отчет на СКД, получается сводная таблица.
Эта таблица сверяется с эталоном.
43. kraynev-navi 455 20.11.15 15:44 Сейчас в теме
Подниму тему.
А можно как-то автоматизировать ввод названий тестов? Или может уже реализовано, не нашел?
Ну типа так:
Перем юТест;

Функция ПолучитьСписокТестов(ЮнитТестирование) Экспорт
	
	юТест = ЮнитТестирование;
        ВсеТесты = юТест.ПолучитьВсеТестыИзМодуляНачинающиесяНа("Тест_"); // ГЛАВНОЕ!
        // в результате в массиве будут два элемента "Тест_ДваПлюсДва()", "Тест_ДваПлюсТри()"
	Возврат ВсеТесты;
	
КонецФункции

Процедура ПередЗапускомТеста() Экспорт
	
КонецПроцедуры

Процедура ПослеЗапускаТеста() Экспорт
	
КонецПроцедуры

Процедура Тест_ДваПлюсДва() Экспорт
	
	юТест.Проверить(2 + 2 = 4, "Значение не верно");
	
КонецПроцедуры
Процедура Тест_ДваПлюсТри() Экспорт
	
	юТест.Проверить(2 +3 = 4, "Значение не верно");
	
КонецПроцедуры
Показать
44. artbear 1180 20.11.15 17:12 Сейчас в теме
(43) kraynev-navi, хороший вопрос, я давно им озадачен и борюсь с этой проблемой!

в "чистом" 1С невозможно получить список методов из объекта/модуля :( рефлексии нет!
в свое время я в 1С++ для 1С 7.7 я смог решить эту задачу и в нашей конфигурации тестировании для 1С 7.7 была такая возможность.

Для 1С с примесями :) в толстом клиенте обычных форм 8.2 для решения этой задачи я использовал написанный нами Информатор
можешь посмотреть метод юТест.ПолучитьПростыеТесты... (точное название не помню) из модуля обработки xddTestRunner

Соответственно для 8.3 или 8.2 УФ нельзя использовать подобный подход и остается юзать один из нескольких вариантов:
  • явно возвращать список тестов из теста через ПолучитьСписокТестов - штатный путь xUnitFor1C
  • если у вас установлен Снегопат, можно использовать написанный мной скрипт "Добавить описания тестовых случае xUnitFor1C" xUnitAddTestsDesc.js)
  • супер-хакерский путь - пишем обработку (или скрипт на 1скрипт), которая разбирает файл обработки, получает текст модуля, разбирает его, и добавляет код по возврату списка методов Тест_ХХХ в метод ПолучитьСписокТестов() :)

По последнему пункту - я сейчас постепенно пишу конвертер тестов из формата 3.Х в 4.Х, решение этого пункта будет в конвертере.
Ура, значит, я хакер :)
45. kraynev-navi 455 23.11.15 14:00 Сейчас в теме
(44)Собственно вопрос возник как раз после того, как сам хотел сделать быстренько и не обнаружил функционала у 1С )))
Обход понятен. Подожду вашу обработку ))

Следующий вопрос касательно обработки тесты_ОткрытиеФормКонфигурации.epf
В конфигурации был словлен следующий критичный случай. При тесте формы элемента журнал регистрации выглядит так. В первой транзакции (177013):
	Тесты "Открытие форм конфигурации"			Операция: Справочник.Организации.Форма.ФормаОрганизации
23.11.2015 9:25:16 (177013)	Данные. Изменение	Константа. Не использовать несколько организаций		
23.11.2015 9:25:16 (177013)	Данные. Изменение	Константа. Использовать несколько организаций		
23.11.2015 9:25:16 (177013)	Данные. Добавление	Справочник. Организации	<Объект не найден> (60:80e20050569e529911e591aaf11bdd91)	


И далее идет удаление в ДРУГОЙ транзакции (505009)!
	Тесты "Открытие форм конфигурации"			Операция: Справочник.Организации.Форма.ФормаОрганизации
....	
23.11.2015 9:25:17 (505009)	Данные. Удаление	Справочник. Организации	<Объект не найден> (60:80e20050569e529911e591aaf11bdd91)	

Все транзакции зафиксированы. Т.е. в первой транзакции константа поменяла свое значение и зафиксировалась. Вторая транзакция константу не привела к предыдущему значению.
Попутно вопрос, а почему они фиксируются? Почему не откатиться?
46. artbear 1180 27.11.15 11:12 Сейчас в теме
(45) Тест открытия формы запускает свою транзакцию.
Насколько я понимаю, константа фиксируется в какой-то внутренней транзакции, которая возникает при проверке формы "Справочник.Организации.Форма.ФормаОрганизации"
В итоге получается вложенная транзакция, результаты которой откатываются при завершении тестов.
47. nicxxx 236 07.10.16 16:19 Сейчас в теме
ветка жива еще? на гитхабе созданный тикет удалился через минуту, поэтому спрошу здесь: в тонком клиенте 8.2 можно как-нибудь запустить обработку xddTestRunner? версия 4.1.0.0 выдает ошибку "Тип не определен (ОписаниеОповещения)", потому что в этой версии платформы (8.2.19.83) еще нет такого объекта языка.
в обычном приложении обработка открывается.
48. pumbaE 633 07.10.16 16:48 Сейчас в теме
(47) nicxxx, почитайте https://github.com/xDrivenDevelopment/xUnitFor1C/releases там есть такой текст
4.0.0.7 последний релиз для 8.2
49. nicxxx 236 07.10.16 18:05 Сейчас в теме
да, спасибо, я уже видел письмо с ответом.
А где все-так более живое обсуждение проекта идет? здесь все утихло, судя по тому, что последнее сообщение было 11 мес назад.
У меня есть пара вопросов, по концептуальным возможностям этой обработки, хочется выяснить перед тем, как начинать углубленное изучение.
50. artbear 1180 07.10.16 20:40 Сейчас в теме
(49) Можешь писать здесь.
Можешь создавать issue на проекте, как ты сегодня и сделал.
Можешь писать в официальном чате https://gitter.im/xDrivenDevelopment/xUnitFor1C

2 последних варианта предпочтительнее.
51. nastrou1c 22 13.01.17 15:12 Сейчас в теме
Здравствуйте, Артур.
Спасибо за Ваш труд. Отличная статья и отличный инструмент.
Есть вопрос по вашему фреймворку xUnitFor1C:
Есть ли примеры использования штатного механизма автоматизации тестирования (http://v8.1c.ru/overview/Term_000000816.htm?printversion=1) в связке с xUnitFor1C?
Если есть - хотел бы попросить пример модуля тестирования.
Пример на github-е с открытием всех форм в решении видел и уже использую. Однако его не достаточно. Желательно автоматизировать именно сценарное тестирование заполнения форм, которое позволяет выполнять штатный механизм и использовать встроенные в фреймворк возможности по обработке и сохранению результата.


52. artbear 1180 13.01.17 15:58 Сейчас в теме
53. nastrou1c 22 15.01.17 12:26 Сейчас в теме
(52) Отлично, спасибо большое за наводку!
54. Artal 06.11.18 17:37 Сейчас в теме
Здравствуйте! Это просто великолепно, когда есть такие люди, как автор данного топика. Артур, спасибо вам за проделанную работу. Мне пока очень трудно оценить объем проделанной работы - но она бесспорно огромна.

Я так же познал дзен tdd, когда программировал на ruby. Это было прозрением. Временем быстрой и качественной разработки.

Теперь же я нахожусь в поиске фреймворка для применения методики tdd для внешних обработок, которые мне необходимо писать для конфигурации УТП 1.2 (конфигурация работает в режиме совместимости с версией платформы 8.2.13).

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

Очень интересно узнать от сообщества 1с программистов, которые по сей день программируют для платформы 8.2, какие именно инструменты (возможно в связке) они используют?
Оставьте свое сообщение

См. также

Развитие 1С программиста Промо

Практика программирования Личная эффективность Бесплатно (free)

Делюсь своим опытом и видением развития 1С программиста.

17.10.2018    18162    0    pashamak    62    

Применение математических достижений в решении сложных задач бизнеса

Математика и алгоритмы Бесплатно (free)

Как правило, самые сложные задачи решаются с точки зрения математики очень легко. Но чтобы найти правильное решение, важно понять бизнес-цель, которую достигает эта задача. О практическом применении математических достижений для эффективного решения сложных задач бизнеса на конференции Infostart Event 2019 Inception рассказал Дмитрий Мишнов.

25.05.2020    1427    0    Mishnov    16    

JSON в запросах 1C#

Практика программирования Бесплатно (free)

Практические примеры работы с JSON непосредственно в языке запросов. Перенос курсов валют между УТ и БП. Требуется SQL Server 2016 и выше.

24.04.2020    2437    0    zhichkin    2    

Визионное программирование

Практика программирования Бесплатно (free)

Новый способ программирования и его практическая демонстрация.

22.04.2020    3322    0    mkalimulin    60    

Метод Кларка-Райта. Оптимальное планирование маршрутов грузоперевозок Промо

Математика и алгоритмы Бесплатно (free)

Одной из наиболее важных задач каждого предприятия, осуществляющего доставку грузов в крупных населенных пунктах, является сокращение издержек. Возможное решение данной проблемы заключается в сокращении пробега автотранспорта и, как следствие, уменьшении расхода ГСМ. Появляются такие вопросы ... - СКОЛЬКО НУЖНО МАШИН ДЛЯ РАЗВОЗКИ КОНКРЕТНОГО ОБЪЕМА ГРУЗА ПО АДРЕСАМ ДОСТАВКИ ? - КАК РАЗБИТЬ ТОЧКИ ДОСТАВКИ НА ОПТИМАЛЬНЫЕ ПО ПРОБЕГУ И ЗАГРУЗКЕ МАШИН МАРШРУТЫ ? ... В этой статье Вы найдете один из многих способов получить ответ на эти вопросы.

10.02.2016    57434    0    mi1man    20    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Математика и алгоритмы Производительность и оптимизация (HighLoad) Бесплатно (free)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    3642    0    ildarovich    7    

Использование машинного обучения для решения инцидентов. Практическое применение

Практика программирования Бесплатно (free)

Продолжаю (и заканчиваю) тему с автоматическим решением инцидентов. Перейдем от теории к практике.

25.02.2020    3136    0    Repich    9    

Использование машинного обучения для решения инцидентов

Практика программирования Бесплатно (free)

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

18.02.2020    4708    0    Repich    17    

Проставление большого количества галочек в активном окне винды Промо

Практика программирования Сервисные утилиты Инструментарий разработчика Россия Бесплатно (free)

Как проставить большое количество галочек подряд в любом окне винды

07.11.2010    29976    0    Boris-Leleko    9    

Часовой на страже логов

Практика программирования Инструментарий разработчика Бесплатно (free)

При поддержке решений, которые установлены у большого количества пользователей на различных системах, очень важно вовремя получать подробную информацию о возникших проблемах. О том, как собирать логи и анализировать полученные данные в трекере ошибок Sentry на конференции Infostart Event 2019 Inception рассказал Андрей Крапивин.

13.01.2020    4788    0    Scorpion4eg    6    

Приватный блокчейн и 1С популярно

Практика программирования Блокчейн Бесплатно (free)

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

02.09.2019    4857    0    mkalimulin    140    

Кодогенерация и метагенерация в 1С

Практика программирования Инструментарий разработчика Бесплатно (free)

В своем докладе на конференции INFOSTART EVENT 2018 EDUCATION Дмитрий Белозеров рассказал о разработке инструмента, позволяющего программно работать с метаданными 1С и писать скрипты для выполнения тех же действий, которые выполняет разработчик в конфигураторе –  с какими сложностями и нюансами пришлось столкнуться, и что получилось в итоге.

26.08.2019    7691    0    kirovsbis    28    

Алгоритм “хвост змеи для заполнения прямоугольной области”. Промо

Практика программирования Бесплатно (free)

При разработке http://infostart.ru/public/275582/ столкнулся с необходимостью распределить выделенные задания на прямоугольную область календаря. В результате родился алгоритм, который может пригодиться не только мне и не только в этой задаче.

20.06.2014    26492    0    milkers    16    

Интеграция сценарного тестирования в процесс разработки

Практика программирования Инструментарий разработчика Бесплатно (free)

Разработчик системы «Тестер» Дмитрий Решитко в своем докладе на конференции INFOSTART EVENT 2018 EDUCATION показывает, что процесс тестирования можно очень плотно интегрировать в процесс разработки, что внедрение тестирования – это возможность развития программиста как такового, позволяющая ему упорядочивать ход мыслей и оставаться «в фокусе». Навыки построения процесса кодирования на стыке с тестированием сокращают время на концентрацию, освобождают от страха перед изменениями и улучшают память разработчика.

08.07.2019    8032    0    grumagargler    7    

Управляй качеством кода 1С с помощью SonarQube

Практика программирования Россия Бесплатно (free)

Управляй техническом долгом проектов 1С с помощью SonarQube. В статье рассматривается пример применения SonarQube при разработке.

07.07.2019    32682    0    olegtymko    229    

Выдержки из книги Чистый код

Математика и алгоритмы Бесплатно (free)

Недавно я прочитал книгу "Чистый код" Роберта Мартина (Robert Cecil Martin). В ней описываются принципы организации и форматирование исходного кода программы так, чтобы в дальнейшем было легко поддерживать такой код. Эта книга является библией для многих программистов, но вот в среде программистов 1С, к сожалению, не очень распространено чтение подобной фундаментальной литературы. Книга более 400 страниц и так много порой лениво читать, да и времени всегда не хватает. По этому я решил выделить в виде цитирования по разделам самые важные моменты. А также снабдил текст своими примерами кода.

16.05.2019    8945    0    FreeArcher    105    

Предметно-ориентированное проектирование (3D) в 1С. Виртуальная машина. Промо

Математика и алгоритмы Бесплатно (free)

Проектирование программного обеспечения - это постоянная битва за простоту.

03.06.2014    39207    0    Evgen.Ponomarenko    88    

О времени и 1С

Практика программирования Разработка Бесплатно (free)

Основы и особенности работы со временем в 1С. Как избавиться от боли при работе в разных часовых поясах. Что такое момент времени. И другое.

01.04.2019    28652    0    YPermitin    60    

Пример создания bridge (http api - tcp) для ККТ "Касса №1" ("К1-Ф")

Практика программирования ККМ Кассовые операции Кассовые операции Разработка Россия Бесплатно (free)

Пример создания bridge (http api - tcp) для ККТ "Касса №1" ("К1-Ф"). Данная статья будет полезна интеграторам, программистам, тем кто работает (интегрирует, разрабатывает) различное ТО либо железки. Версия и релиз технологической платформы не имеет значения.

17.03.2019    5522    0    dmarenin    0    

Вывод текста в окно сообщений (Теперь и для 8.2 !!!) Промо

Практика программирования Россия Бесплатно (free)

Позволяет вывести любой текст набранный с клавиатуры в окно сообщений. Теперь работает для любых конфигураций 1с предприятие!!!

29.05.2009    39076    0    Ёпрст    208    

Быстрее чем INSERT! BULK-операции и примеры использования

Производительность и оптимизация (HighLoad) Практика программирования Внешние источники данных Перенос данных из 1C8 в 1C8 Разработка Бесплатно (free)

Microsoft SQL Server поддерживает так называемые BULK-операции, используемые для быстрого изменения больших объемов данных в базе. В статье пойдет речь о практических примерах их использования. Все примеры сделаны в контексте платформы 1С (а как иначе).

09.03.2019    19762    0    YPermitin    40    

Как писать понятные коммиты

Практика программирования Разработка Россия Бесплатно (free)

Как писать сообщения коммитов так, чтобы потом не было мучительно больно.

06.03.2019    11519    0    Scorpion4eg    35    

Внутреннее качество разработки конфигураций 1С Промо

Практика программирования Математика и алгоритмы Бесплатно (free)

Пиши с верой в то, что твой читатель - это маньяк с дробовиком, знающий твой домашний адрес. Размышления на тему внутреннего качества кода при разработке/доработках конфигураций 1С.

21.06.2013    36973    0    ig1082    50    

Что такое алгоритм?

Математика и алгоритмы Бесплатно (free)

Как ответить на этот вопрос и не попасть пальцем в небо.

25.02.2019    6721    0    mkalimulin    274    

Подготовка ребёнка к ЕГЭ по информатике. Часть шестнадцатая

Практика программирования Разработка Бесплатно (free)

Поиск выигрышной стратегии, завершающая статья.

22.02.2019    4835    0    vasilev2015    0    

Горячие символы или новое это хорошо забытое старое. Промо

Практика программирования Бесплатно (free)

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

07.06.2013    25684    0    vasiliy_b    70    

Подготовка ребёнка к ЕГЭ по информатике. Часть тринадцатая

Практика программирования Разработка Бесплатно (free)

Исправление ошибок в программе, часть вторая.

20.02.2019    5060    0    vasilev2015    3    

Обратная связь от наших пользователей. Кнопка "Обратная связь" Промо

Практика программирования Бесплатно (free)

Хотите помочь пользователю написать Вам все, что он думает о вашей разработке? Вы точно не боитесь этого и идете навстречу пожеланиям людей? Тогда не поленитесь и добавьте небольшую кнопку в Вашу разработку - это кнопка "Обратная связь". Это поможет пользователю прямо из вашей обработки или конфигурации отпарвить Вам письмо, написать комментарий на инфостарте или открыть страницу с вашей разарботкой. При этом пользователю не надо будет вспоминать, где же он нашел эту разработку!

10.12.2012    20427    0    www2000    8    

Алгоритм ведения дебиторской задолженности(Часть 1) Промо

Математика и алгоритмы Дебиторская и кредиторская задолженность Дебиторская и кредиторская задолженность БУ Бесплатно (free)

Алгоритм построения дебеторской задолженности с привязкой отгрузки и оплат

29.11.2012    19592    0    anterehin    15    

Подготовка ребёнка к ЕГЭ по информатике. Часть восьмая

Практика программирования Разработка Бесплатно (free)

Шифрование и дешифрование информации. Закон Фано

05.02.2019    4777    0    vasilev2015    1    

Расширяем свой багаж

Практика программирования Разработка Бесплатно (free)

Алгоритм решения возможной нетиповой задачи на собеседовании.

29.01.2019    5490    0    scientes    15    

Вредные советы (загрузка из таблиц Excel) Промо

Практика программирования Загрузка и выгрузка в Excel Россия Бесплатно (free)

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

01.04.2012    25443    0    opx    23    

Криптовалюты, а также иные взгляды на природу денег в терминах 1С

Математика и алгоритмы Бесплатно (free)

Это отчасти полемическая статья. Я задумал написать ее как ответ на другую хорошую статью о криптовалютах. Хотелось поспорить с некоторыми утверждениями автора, а ещё больше с некоторыми комментариями. А чтобы текст был более понятным для местной аудитории, я решил использовать, где только возможно, терминологию и практику 1С.

28.01.2019    5640    0    mkalimulin    89    

Подготовка ребёнка* к ЕГЭ по информатике. Часть пятая

Практика программирования Разработка Бесплатно (free)

Маршрутизация. Протокол IPv4 для ЕГЭ.

27.01.2019    4998    0    vasilev2015    5    

Лицензии на программное обеспечение: что, как и для чего Промо

Математика и алгоритмы Россия Бесплатно (free)

Обзор и краткий сравнительный анализ основных видов лицензий на программное обеспечение (ПО). Специалисты и знатоки вопроса не найдут здесь ничего нового. Тем же, кто не владеет информацией, возможно, что-то здесь окажется полезным.

17.07.2012    153082    0    Alraune    36    

Подготовка ребёнка* к ЕГЭ по информатике. Часть четвертая

Практика программирования Разработка Бесплатно (free)

Решение систем логических уравнений повышенного уровня сложности.

25.01.2019    5186    0    vasilev2015    0    

Как писать код? Технологии древних цивилизаций, или все новое - это хорошо забытое старое

Математика и алгоритмы Бесплатно (free)

Все современные технологии - это развитие и доведение до ума (или маразма) древних идей. За последнее время не придумали ничего нового - все, что мы видим, было придумано тысячи лет назад. Не является исключением и программирование, которое в сути своей является переводом с языка условностей технического задания или заявки пользователя в формализованный и абсолютно точный язык математической логики. А логику придумали (по крайней мере первыми опубликовались в ведущих научных журналах) еще древние греки.

23.01.2019    10987    0    starik-2005    43    

Подготовка ребенка* к ЕГЭ по информатике. Часть третья

Практика программирования Разработка Бесплатно (free)

Алгоритмы рекурсии, логические задачи. Подготовка к ЕГЭ.

22.01.2019    6606    0    vasilev2015    0    

Разработка и сценарное тестирование с Vanessa-ADD. Установка инструментов. Запись действий пользователя и выполнение сценариев

Практика программирования Бесплатно (free)

Вторая часть цикла публикаций, посвященных Vanessa-ADD и автоматизации тестирования.

21.01.2019    27662    0    Vladimir Litvinenko    94    

Подготовка ребенка* к ЕГЭ по информатике. Часть вторая

Практика программирования Бесплатно (free)

Примеры на Паскале. Если сам родитель* - поддержи ! Если сам водила - посигналь !

19.01.2019    5215    0    vasilev2015    0    

Подготовка к ЕГЭ сына - школьника (по информатике)

Практика программирования Бесплатно (free)

Примеры на Паскале. Если сам отец - поддержи ! Если сам водила - посигналь !

17.01.2019    5837    0    vasilev2015    50    

Роберт Мартин: "Будущее программирования" / Robert Martin: "The Future of Programming"

Математика и алгоритмы Блоги Бесплатно (free)

Перевод-транскрибация выступления.

14.01.2019    14531    0    Vladimir Litvinenko    38