<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Поспорю с тезисом:
Никому, ни одному руководителю не нужна была эта технология именно из-за увеличения локальных сроков разработки.
Если договорится, что выполненной задача считает тогда, когда пользователь может нормально работать, то сроки разработки одинаковые. Их только считают неправильно.
А так спасибо за труд =)
+ втянутся в тестирование неочень легко, надо хотя бы пару книжек прочитать и научиться писать тестируемый код. А самому это довольно-таки тяжело.
Абсолютно согласен только тогда, когда твой руководитель замыкает весь цикл разработки, а когда руководитель разработки ПО стремится быстрее отдать в отдел тестирования, то тут его мало интересует качество кода до того момента, пока ему в KPI не поставят показатель количества возвратов на доработку!
Олег, интересная статья.
Только названия инструмента-наследника от VB и xUnitFor1C я так и не увидел 🙂
Мне понравился термин «РМП» — разработка через муки пользователя, 🙂 помимо многих мыслей.
Проблема в головах трудно решаемая задача, но решаемая)
Также, на мой взгляд, существенные трудности вносит некоторая не совместимость подхода TDD с 1С, его можно относительно эффективно использовать при части решаемых задач.
(3) А вот и уважаемый мною, artbear!
Проект объединен в единый общий репозиторий ADD
— объединенный проект содержит в себе
BDD — bddRunner
TDD — tddRunner
единые расширения для тестирования
(4)
Да уж, хоть как то сделать легче пользователям — это научиться правильному подходу самому!
(5) Не соглашусь в данный момент, на текущий момент не встречал таких задач, если приведете пример, будет круто!
(4)
Новый холивар: TDD vs DUS
TDD — test driven development
DUS — development through user suffering
Хорошая статья. Знакомо до боли.
Но я так и не понял, чем всё закончилось? Автор, где сейчас работаешь? Всё также подпольно пишешь и запускаешь тесты? Или уже заразил всю команду зелеными кружочками?
(9)
Надеюсь не закончится еще очень долго!
(9)
Так точно.
(9)
К сожалению, нет…никому кодить в два раза больше строк кода не хочется.
(10) Дымовые тесты же всем показывал?
Вообще, когда/если ты уйдешь с текущей работы, к тебе будут обращаться с вопросами про вю эту магию.
Сейчас даже немножко попроще — и материалов полно (платных и бесплатных), и инструменты заметно подтянулись + вышли новые.
Но всем надо «здесь и сейчас», а играть «вдлинную» никто не хочет или не умеет.
Да меня после зеленых кружочков никто не понял, почему сроки по новой подсистеме неоправданно высокие!
А если бы про «дымовые» заикнулся — все бы расценили как попытку поджёга офиса;-)
(11)
Так и есть, заниматься можно постоянно повышая свой профессиональный уровень.
(11)
Причины, на мой взгляд, очевидны, я их описал в публикации и изменить парадигму в коллективе сможет только тот, кто будет заточен на качество с большой буквы К.
(7)Во-первых, если внимательно читали, то я утверждаю, что его эффективно использовать при части решаемых задач. Это значит, что деньги/время/эффективность при некоторых условиях перевешивают весы в другую сторону.
Во-вторых, расскажите мне как вы обходите отсутствие возможность создать mock объекты в 1С.
(13)
А пока никак на данной ветке своей эволюции в разработке через TDD.
Я прочитал Вашу статью и нашел много полезностей, которые еще предстоит осознать и пощупать на практике.
Но при всем при этом, тому функционалу, который мне приходилось обвязать тестами, не требовались ни подставные объекты, ни заглушки.
Я даже не представляю пока как их применить в тестировании в 1С.
Есть статьи на эту тему или достойная книга на Ваш взгляд?
Если будет больше статей практического характера, то и не будет, постоянного, простите, нытья, о том, что тестирование — круто, но большинство настолько слабы душой, что не тянут. Нет, ну серьёзно, если есть желание двигать тему — нужны тематические материалы, а не рассказы: «никто не использует тестирование, а ведь это так круто, ведь я попробовал и у же получается».
(15) Абсолютно верно, только учить нужно тем, кто в этом гуру, а тем кто начинает путь, если есть желание, рассказывать каков он, этот путь.
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания!
Иначе, можно так научить, что переучивать дороже станет.
(16) Ждем следующей статьи, не нужно обучающей, просто поделитесь практическим примером наработок, к чему пришли, какие сложности и т.д. с точностью до строки кода. Понимаете, тема тестирования уже сильно взбудоражена и до нас вами, и не очень большое количество статей, где об этом рассказывается на практических примерах, начинает раздражать большую гвардию программистов, которые пытаются и не получается (не у всех хватает выдержки, но и ведь она не обязательно должна у них быть!)
Да, более практической части, конечно, не хватает.
Практики и технических деталей нужно больше, конечно.
Статья не предполагала тематику вида: азы входа в TDD. Скорее показать реалии TDD при входе, в том числе, подготовить программистов к тому, что их старания, возможно, и это печально, не будут оценены положительно — это Ваша инициатива сделать Мир разработки 1С лучше. К этому нужно быть готовым и большой успех, если Ваша команда пропагандирует это.
Но над конструктивными замечаниями подумаю на будущее — как это грамотно оформить в виде статьи. Благодарю за конструктив!
(14)
1. В некотором приближении макет можно назвать мок объектом.
2. В рамках TDD и 1С я видел только статьи от Артура Аюханова и Ко.
3. По-моему опыту, эффективно обвязывать тестом блоки функций (относительно большой кусок). Обвязывать маленькую функцию слишком времязатратно и не эффективно (время/деньги/качество/люди).
4. Читать другие книги по TDD тяжело, т.к. проекция примеров в 1С нельзя спроецировать один в один (Книга «Экстремальное программирование: разработка через тестирование»).
5. У нас в компании, я в ближайшее время планирую провести вебинар посвященный тестированию юнит и TDD, думаю, я выложу на youtube канале некоторую интерпретацию некоторое время после.
(10)
Я разработчика спрашиваю: «как ты докажешь, что твое решение правильное/работоспособное?» Хороший ответ, у меня есть тест)
(11)
Или забросят, если никому не интересно, то продолжать не будут. Пробовал внедрять «промышленные подходы» после аналогичного курса. Всё из под палки, потом и самому всё это надоело.
«много букв» — это предупреждение для молодежи, читающей только твиттер? ;-0
(20)
А по-моему наоборот. Легко получается писать unit-тесты, если функция маленькая и имеет мало зависимостей. Например, очень просто написать тест на функцию, чьими параметрами будет выступать пара документов и элементов справочников. Тогда и макеты не нужны. Можно создать пару элементов справочника только с нужными зависимостями.
К примеру, документ реализация, 2 номенклатуры и один склад. И мы уже можем протестировать движения документа по складскому контуру.
Т.е. в качестве границ выступают не интерфейсы (к примеру), а метаданные. И чем к меньшему кол-ву метаданных мы сведем, тем более тестируемый и простой получится код.
Если писать unit-тесты сразу, то получается не так трудозатратно и выигрыш больше. Но большинство существующего кода 1с тестируется плохо, с вами согласен. Зависимость от БД слишком велика.
Следует ли материал трактовать так, что ТДД неприменимо в маленьких (насколько каких?) компаниях, обслуживаемых 1-2 1Сниками, которые не занимаются промышленной разработкой на продажу..?
Конечно же нет, и один разработчик может покрыть тестами свою конфу и спать спокойно!
Когда все фичи покрыты тестами, то и вносить изменения в разы проще, не боясь выпускать релиз в production!
Мне не нравится как я пишу, и качество разработок моих (но я и видал код таких хомячков — что мои каракули = верх совершенства). Я пробовал и регулярно (но нечасто), пытаюсь мелкие задачи через «тдд» писать (по сермяжному, по доморощенному, но хоть как-то улучшить качество разработки). Но все упирается как раз в это «нужно вчера». Задачи для бизнеса (не в ИТ-компании!) возникают по инициативе бизнеса. А (небольшой) бизнес принципально не способен планировать разработку инструментария для решения его задач. Почти всегда это надо сейчас и вчера. И что делать? Конечно, понятно, что — плюем на все «тдд» и срочно пилим «как есть». Замкнутый круг.
(28) Когда пишешь под «сейчас и вчера», тогда и происходит реальное тестирование. Собственно, откуда ТДД произошло? Еще Дейкстра показал, что протестировать программу невозможно (начиная с некоторого объема). А тестировать надо. Значит, надо создать надежный остов (как — это другой вопрос) и помаленьку наращивать на него оттестированные кусочки мяса. В ИТ-компании это реальная проблема (релизы, версии, преемственность, сопровождаемость и т.п.). А в бизнесе появилась задача — делаем (пишем) канву. Даже распечаткой результатов не заморачиваемся. И юзерам в зубы. Через пару не дней, часов косяки налицо. Далее постепенно растим функционал. Так что никакого замкнутого круга.
(29) ээээ! это не катит когда цена ошибки велика. В работу надо отдавать «правильный» вариант. а ошибки иногда бывают ну не очень явные… и времени на тщательное программирование — нет совсем.. вот и костылишь — основное пишешь тщательно по возможности, а оно хреняк и сработало «неосновное» — а там конь не валялся, в целом-то вроде и правильно, но не очень…
(30) Понятно, что от этого, по видимому, никуда не дется. Это — ПЛАТА за бизнесовское «надо вчера»…
(29)
Будет очень печально, когда встанет отгрузка со склада или еще какая-либо «процессно-значимая» фича.
Я был свидетелем разбора таких ситуаций у ген.дира, когда руководители разработки, тестирования и системного анализа объясняли за что они получали заработную плату и медленно намокали майки, а лица становились багрово-алыми.
Конечно же, это не норма такой разбор полетов — но повышать качество выпускаемых фич однозначно надо, моё ИМХО.
Тестирование, всё же, не единственный вариант повышения качества разработки. Есть и другие, более независимые от команды и др. внешних факторов и не влияющие на скорость разработки в худшую сторону.
Есть, например, внутренняя автоматизация. У нас работает база-центр обменов и обработка обновления рабочей базы нединамически одной кнопкой (инструменты моего изготовления с учетом специфики).
Также есть повышения качества самого кода. Я не про унылые стандарты с ИТС (но и не против них). Отличная книга «Совершенный код» Макконела. Или написание запросов (почти) без конструктора (консоль запросов Инструментов Разработчика помогает автодополнением текста). Или освоение СКД в конце-концов (меньше кода — лучше его качество).
Как-то экспериментировал с TDD, но моё впечатление, что более высокоуровневые приемочные тесты типа BDD это проще и более «по-1Сному», чем на каждую тривиальную функцию лепить тест по канонам классического TDD. (Но в те времена 1С-BDD было неразвито и как-то забросил тему.)
(33) как всё то, о чем Вы написали поможет проверить 159 фич, которые могут быть «затронуты» новым релизом и гарантировать работающий функционал утром при ночном обновлении продуктива?
(34) Очевидно, никак 😉 Но это поможет создавать меньше косяков изначально…
(35) Вы пишете об инструментах создания/генерации кода, но не о механизмах проверки методов/фич — согласитесь, разный контекст.
(33) Согласен с тем, что есть и другие способы повышения качества.
Лучше применять все варианты, причем системно, а не эпизодически.
Статический анализ кода, полная расширенная проверка, прогон через SonarBSL, дымовые тесты разных видов, продвинутые инструменты, отладка запросов, авторазвертывание, сервер непрерывной интеграции, сервер развертывания и т.п. и т.д.
Ух куда нас занесло) следующая статья про новичка в DevOps…
(32)
Я про ИТ-фирмы не говорю. Три руководителя = перебор для любой другой фирмы.
Такое может быть только у менеджера. Руководители знают Козьму Пруткова: и при железных дорогах сохраняй двуколку. Внедрение новой фичи не может сопровождаться разрушением старых механизмов — ну, при нормальном руководстве, конечно.
Некогда тесты писать, тут даже говнокодить не успеваешь, давай-давай 🙂
К сожалению, в большинстве случаев ситуация именно такая.
Серьезные подходы получается внедрять и они окупают себя только в серьезных продуктовых командах, которые востребованы в ограниченном количестве.
Где большие сложные продукты с большим количеством пользователей, поставленный цикл разработки и т.п. и т.д.
А не когда разработка идет в полтора лица, а цикл разработки разбит на случайные итерации от одного подзатыльника до другого с требованиями «на вчера».
(39) Как раз таки, это не была ИТ организация. Было создано ИТ подразделение со своими руководителями по направлениям.
(8) ))
(20)
Насчет моков. У нас тоже достаточно большое поле возможностей и фантазии.
1. Тесты, обычно, обрамляются началом/откатом транзакции. Можно создать свой тестовый документ/справочник, записать и использовать его ссылку. При откате транзакции — будто ничего и не было.
2. Примерно тоже, что и п.1, только объект можно заполнить какими-то предварительно сериализованными данными.
3. Как иногда в типовых, подменять Структурой.
(20) Насчет
Ну не знаю… Как по мне, эта книжка достаточно правильно заряжает. И главное, вдалбливает режим «красный-зеленый-рефакторинг». Даже если этого не соблюдаешь, то как-то всегда помнится об этом.
(40) Есть такая ситуевина.
Тут нужно автоматизироваться. Это почти без вариантов.
Т.е., нужно иметь возможность — куда-то выкладывать тесты. На сетевой ресурс, на интранет-гит, на внешний гитлаб, еще куда-то.
И нужны постоянные автоматические прогоны выложенных тестов на тестовом контуре. Результаты — должны публиковаться где-то. И/или пусть приходят по эл.почте.
Тогда это будет хорошим стимулом писать тестируемый код и сами тесты.
Это я себя так подбадриваю;)
Нужно уже собраться и написать какую-то такую сборочно-тестовую линию.
Я, в свое время, пошел по альтернативной ветке — не по учениям Серебряной пули. Написал и почти не развиваю обертку Ванесса-Раннер/Деплойка для Jenkins для автоматизации развертывания.
Хех, нужно уже написать линию тестирования.
(40)
Корень проблемы в том, что повышать свой профессиональный уровень хотят единицы, все остальные из «под палки».
Я приведу пример из своего управленческого опыта:
— объявил всем сотрудникам о том, что бюджет на обучение не ограничен (за это, конечно, особая благодарность моему руководителю, который «услашал» меня), выбирайте любые курсы — учитесь, в том числе с выездом в мск.
— только один сотрудник из 40 прошел обучение и сдал на спеца с первого разва в УЦ №1 за два года.
Вот так то!
(46) очень круто всё разложили:
— конечно, покрывать тестами существующий функционал — это против философии сначала тест потом код, но абсолютно согласен, что на этом можно неплохо набить руку. Сам грешу этим.
За конструктив огромная благодарность Вам!
(47)
я знаю этого сотрудника)) респект за статью
(49)
Благодарю, Антон!
(47) Или у вас очень странные сотрудники, или вы что-то не договариваете по условиям обучения.
(51)
Сотрудники были одни из лучших)
(51)
Никаких обременяющих условий быть не могло, в принципе, компания могла себе это позволить.
В долгую перспективу выигрывали все.
(52) Тогда согласен, что 1С-ники в большинстве своём ленивые :))
(53) Лень — это не всегда плохо, лень + задача в срок с заданным качеством = эффективность!
(41)
Ужас какой. И сколько времени прошло от создания подразделения до обнаружения его неэффективности?
(55) К сожалению или к счастью, я не участвовал в этом процессе, да и про эффективность никто выводы при мне не делал.
Уверен, что эффективности можно достичь в любой структуре, вопрос полномочий и знаний того, кто управлять будет.
(54) Тогда сотрудники правы, получается. Им не нужны были курсы, чтобы быть эффективными, только и всего.
(57) в их матрице мышления — да!
(56)Ну, как же?
гиты, шмиты….
как-то договорился с коллегой, что будем родное хранилище использовать. ну хотя бы так
ок, говорит, погнали…
гнали мы не долго, до возвращения начальника из отпуска
такие дела
(59) Не участвовал в создании и не фиксировал его НЕ эффективность. По сути, это структура очень хорошо показывала количество возвратов на доработку, при этом не нервируя пользователя на продуктиве.
(61) Понял. Структура показывает, не нервирует…. все по феншую. Кстати, китайцы, когда все по правилам, а толку нет, херят правила. Поэтому у них 7% роста ВВП, а у нас 0.
Если на то пошло, то TDD своей основной и самой вкусной частью — про юнит-тестирование. А в 1С с юнитами несколько особая ситуация.
Половина настолько простые, что овчинка выделки не стоит, а половина настолько «завязанные», что тоже овчинка выделки не стоит (мокать устанет рука да и смысла особого нет).
Функциональные и интеграционные автоматические тесты — это да. Это реально полезно. Только классическое TDD не про них.
(63)
Макконелл, в том числе, писал о том, что код должен быть со «слабыми» связями.
Когда Вы изначально пишите тест, а после сам код, то это правило соблюдается как нельзя лучше.
Пока я вижу плюсы…наверняка, будут и сложности, но это скорее будет ограничением применимости технологии именно в 1С, но никак не посыл к отмене.
(64) Удачи. Хотите попробовать фигней пострадать — ваше право.
А лично я бы сосредоточился не на эфемерном TDD в 1С, а хотя бы на простейших функциональных и интеграционных тестах.
Чтобы получать ответ на самые насущные вопросы:
— не сломался ли запуск 1С
— не сломалась ли работа форм
— не сломалась ли работа документов на тестовых наборах данных
Так даже до этого руки не доходят.
(65) И Вам удачи, у каждого свой путь!
Ну и ждем от Вас статьи на описанные Вами темы.
(66)
Жаль вас разочаровывать, но вроде бы я не давал повода для такого рода чаяний.
(64)
Я бы акцент сделал на «ограничением применимости технологии именно в 1С».
ТДД был придуман на ООП. Именно там это работает так, как нужно.
Даже Серебряная Пуля пришла к тому, что чисто модульные тесты в 1С не панацея. И сместили разработку несколько в другое русло.
(64)
Вот когда в 1С будет возможно использование SOLID, DI, IOC без костылей, тогда и можно говорить о TDD.
Сам использовал TDD на ОПП. Реально стоящая вещь. Обеими руками за эту технологию. Но в реалиях 1С об этом можно только мечтать.
Сама методология ТДД — сначала тест, потом код не совсем подходит когда пишешь с 0.те «творишь».
Вот для исправления ошибок — вполне можно
(70)
Как раз наоборот. Именно когда с нуля. В любом случае, сразу с нуля писать код без предварительного обдумывания структуры и чернового плана, мягко говоря «код в никуда».
Именно TDD помогает сразу писать структурированный и покрытый тестами код. По другому просто сложно. И главное: код получается малосвязанный. TDD прямо навязывает использовать «включение» зависимостей.
Вот для исправления ошибок, это уже не TDD. И не каждый код можно «покрыть» модульными тестами. Да же не беру код завязанные на внешние факторы. Просто после «творишь» на это спагетти не всегда можно написать тест.
(71) писать в стиле ТДД вполне можно не писав при этом сами тесты.
когда творишь процедуры могут по 100 раз меняться — это нужно 100 х 500 тестов переписывать
PS творишь — это НЕ то когда пишешь по ТЗ. дорбавьте на форму реквизит «А». при его изменении должен измениться реквизит «Б»
(72)
Это как? Само название как бы говорит, что тесты вначале.
Если речь про попытку «писать в стиле ТДД» в 1С, то даже обсуждать это не буду. Уже говорил почему.
TDD это совсем не то, что вы себе представляете. Это нужно вникнуть в методологию. Научиться мыслить в нужном направлении.
Это как начать писать код под управляемые формы после обычных. Требуется перестраивать мышление, а не пытаться на УФ писать по привычке как на ОФ.
Чтобы не было недопонимания: это не прямая аналогия.
(73) Писать в стиле ТДД — писать код, который легко тестировать
(74) это не TDD.
Вся прелесть TDD в том, что вначале пишется тест того, что должно получиться. Заметьте, не как, а что. Запускается тест. Если тест проходит, значит есть ошибка. Именно так. Ошибка!
Первый тест никак не должен проходить.
Если тест не прошел, то пишется простейшая реализация модуля. Ровно такая, чтобы тест прошел.
Дальше интересней. При необходимости пишется тест проверяющий пограничные значения. И самое главное. Делается рефакторинг того простейшего кода, который был написан только для прохождения теста. При каждом изменении кода прогоняется тест. Этим мы отслеживаем работоспособность кода.
Пример: Нужно создать метод деления чисел.
1. Пишем тест: Проверяем, что 6/2=3
2. Проверяем метод. Ошибка. Отлично.
3. Пишем код: Возврат 3. Да, в данном случае утрированно, но в общем смысле именно так в простейшем случае. Не пытаемся полностью написать сложный метод.
4. Проверяем. Тест проходит.
5. Пишем тесты на пограничные условия. Типа деления на 0. И другие выборочные значения.
6. Проверяем. Не все тесты проходят.
7. Изменяем код под новые тесты.
8. Тесты проходят.
9. При необходимости делаем рефакторинг. Цель: оптимизировать вычисление.
10. Прогоняем тесты. Если проходят, то готово. Иначе повторяем с п.7.
(74) Не. TDD — это достаточно специфическая штука.
Просто его настолько часто поминают всуе, когда разговор заходит за юнит-тестирование, что люди которые не сильно в теме начинают их как синонимы использовать. И юнит-тесты и написание хорошего кода, в том числе легко тестируемого — это все и без TDD прекрасно себя чувствует.
Писать с стиле ТДД и использовать методику ТДД для разработки — это разные вещи
(77) «Писать в стиле ТДД» — если при этом вы не пишите тестов ДО кода, то фраза будет некорректна.
Если вы пишите хороший тестируемый код и даже пишите потом отличные тесты на этот код — то так и говорите. Не нужно приговаривать про TDD — он никакого отношения к этому не имеет, вы только введете людей в заблуждение. Это вообще разные плоскости.
TDD — это всего лишь идеология использования тестов в качестве ТЗ. Формулируете требования, воплощаете их в тестах и только потом реализуете код, удовлетворяющий этим требованиям. Именно в таком порядке. Тесты могут быть говно, код может быть отстой, зато можно смело заявлять, что вы ведете разработку по TDD и это будет чистая правда.
(78) Что такое ТДД — это понятно, просто вопрос: реально ли кто-то использует ТДД для прототипирования системы?
(79) Рекомендую почитать книгу Р. С. Мартина и М. Мартина «Принципы, паттерны и методики гибкой разработки на языке C#»
(79) Апологеты утверждают что да — используют. Типа фишка даже не столько (или не только) в покрытии кода тестами как таковом, сколько в особом методе мышления и подходе к разработке. Который форсит думать о правильных вещах вовремя и из которого вытекает куча полезных плюшек.
(21)
есть же внутренняя приёмка (или демо в скраме)
А самописный тест может отличаться от конечных ожиданий. И да, тест <> правильное решение.
(48) Покажите хотя бы один ваш «»тест»? 😉
(27)
Свою? Один? Полностью всю конфу? Вы сильно преувеличиваете.
(16)
Возможно, гуру и я стану когда-нибудь в этом вопросе, вот тогда и возникнет право передать знания!
Иначе, можно так научить, что переучивать дороже станет.
Добрый день!
Спасибо за вашу статью и желание донести до сообщества информацию, что результаты разработки через тестирование являются более надежным и предсказуемыми, нежели результаты разработки без тестов вообще. Программист может быть уверен в том, что функции его модулей или обработок работают именно таким образом, как это было задумано. Разработка через тестирование очень сильно влияет на образ мышления программиста. К таким выводам я пришел, когда я программировал на ruby и затем php.
В данный момент мне необходимо дорабатывать функционал конфигурации УТП 1.2 которое работает на ОФ в режиме совместимости 8.2.13.
В саму конфигурацию я пока не лезу. Попробовал расширить функционал путем написания внешних обработок и понял, что мне очень не хватает инструментов для тестирования. Жуть как не хватает!
Очень не хватает ментора, который мог бы помочь преодолеть трудности на пути освоения, на мой взгляд правильного подхода к разработке 1С . В свою очередь обещаю быть полезным в ответ. Я очень люблю читать, но прямое общение с людьми незаменимо. Очень прошу откликнуться того, кто мог бы стать ментором для начинающего 1С программиста, а может и партнером или даже другом.