<?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='\
Тестировать приватную/внутреннюю функцию — это зло 🙁
Если тестировать внутреннюю функциональность, можно нарушить состояние объекта.
Всегда нужно тестировать именно поведение, т.е. публичный интерфейс, соответственно, публичные методы
Использование «ВыполнитьВКонтексте» также зло 🙁
Пояснения (не в порядке важности)
Интересный ход. Иногда при программном заполнении каких-нибудь форм нужно вызывать код обработчиков событий, а они не экспортные. Подобным образом можно будет добраться и до них.
(1) artbear,
Согласен.
Результат теста отдельной внутренней функции заключается только в том, что мы проверили именно эту функцию. Хорошо, она работает. Но может быть она вовсе не вызывается в каких то необходимых случаях, или параметры в нее передаются не те, что вы ожидаете.
Правильней тестировать программный интерфейс модулей или же вообще пользовательскую функциональность программы (автоматизированное тестирование от 1С) .
(1) artbear, тестирование внутренних функций не отменяет тестирование публичных.
Я конечно доверяю твоему опыту, и использую вашу разработку, а также внимательно слежу за развитием проекта xUnitFor1C. Но однако, прошу указать ссылку, где написано, что «тестирование внутренних методов это зло». Или может кто-нибудь из присоединившихся к этому высказыванию кинет ссылку на классику.
У Роберта Мартина «Чистый код» написано обратное. Он наоборот пишет тесты на каждую функцию.
Юнит-тесты — это тестирование «маленьких» функций. А тестирование поведения — это уже приемочные тесты. Или я не прав?
(2) artbear, согласен по поводу замечания насчет читаемости.
Делать методы публичными, чтобы только их протестировать — нарушение инкапсуляции, тоже некрасиво.
Мне тоже кажется, что данный метод — это зло. С другой стороны, тестирование позволяет найти не более 30% ошибок, при этом тестирование по эффективности в 5-10 раз хуже, чем инспекции кода и парное программирование (Макконнелл). Меняйте методы разработки и вам не придется «страдать» такой ерундой.
(7) starik-2005, просто с тестированием вы на этапе программирования эти 30% уже исправляете, а не в продакшине и хоть немного уверены, что у вас не будет регрессии.
(5) Согласен. Я пишу и не для публичных методов тесты тоже.
(0) для безопасности советую или определенную роль добавить или же проверять константы тип имя базы, что-бы данный код не запустился на рабочей базе.
(10) pumbaE, абсолютно согласен. В целях безопасности следует адаптировать процедуру. Либо удалять ее при сборке конфигурации для продуктива (если хранится в git’e)
(5)
Почитай, например,
или
или гуглить «тестирование приватных методов»
Юнит-тесты также должны тестировать поведение, но только маленьких кусочков функциональностей.
мы же тестируем, чтобы гарантировать, что наш код выполняет свои обещания, т.е. отвечает за свое поведение.
И безопасность из (10)
и (2)
и соблазн быстро «наговнокодить» через ВыполнитьВКонтексте
и т.п.
(12) artbear, в статьях содержатся аргументы и «за» и «против».
из visual studio 2012 возможность тестирования закрытых методов видимо была удалена не случайно. НО вместо нее осталась возможность тестирования protected-методов.
Получается, что тестировать нужно, но не все подряд внутренние методы.
По поводу «возникает соблазн быстро «наговнокодить» через ВыполнитьВКонтексте» — абсолютно согласен.
В общем и целом, делаю для себя вывод, что аргументов «против» — больше. И использование предложенной мной методики нежелательно. Однако такая возможность есть, и статью оставляю, для расширения кругозора, а также ради дискуссии, развернувшейся на основании нее.
Большое спасибо всем отписавшимся за конструктивную критику.
Было интересно и полезно услышать разные мнения.
(8) pumbaE, в прожакшн попадает код после инспекций, которые сокращают время поиска багов в 3-4 раза и имеют эффективность поиска ошибок до 75%. В литературе инспекции описаны (я ссылке привел на автора). В IBM и многих других компаниях давно уже не занимаются тестированием — вместо этого проводят инспекции кода. И это является одним из обязательных условий достижения CMM 5 уровня.
(4) ardn, на то оно и юнит тестирование, что проверяем отдельные функции. И да, дейстивтельно необходимо уметь писать правильные тесты.
и конечно это не отменяет тестирования поведения
(17) starik-2005,
>> В IBM и многих других компаниях давно уже не занимаются тестированием
А где можно подробнее об этом почитать?
(19) o.nikolaev, в книге «» Макконнелла.
P.S.: на всякий случай хочу пояснить, что тестирование достаточно больших программных комплексов подразумевает сборку релиза в течение достаточно длительного времени. При тестировании происходит визуальный контроль работы функционала, который не позволяет выявить большую часть проблем. Тестирование позволяет увидеть явный баг кода и в этом плане уходит не дальше, чем просто проверка на компилируемость. В то же время альфа- и бета-тестирование на реальной аудитории позволяет выявить большое количество ошибок (бета-тестирование в 1000 и более организаций — от 97%). Но это фактически использование продукта в стадии beta, когда его не используют в продакшн, а просто смотрят, как оно работает (типа установки новой платформы 1С и откат впоследствии к старой, ибо на продакте выявляются такие баги, о которых на стадии бететеста тестовой версии платформы никто не подумал или, обнаружив, не сообщил в 1С). Краудсорсинг в последнее время используется всеми большими компаниями. Та же W10, обновление на которую изначально прорекламировали, как чуть ли не амнистия пиратским копиям. Из-за этого бета винды и отправляла гигабайты данных в M$, что послужило поводом даже для разбирательства в суде на тему «слежения за пользователями».
P.P.S.: юнит-тестирование выявляет проблемы в маленьком клочке нового кода, позволяя открыть все формы, закрыть их, провести каждый вид документа или сформировать каждый вид отчета по заранее заготовленному шаблону. Суммарные трудозатраты на поддержку актуального состояния юнит-тестов примерно в 3 раза больше, чем трудозатраты на регулярные инспекции. И если инспекции производятся в соответствии с рекомендациями по CMMi, то выявленные ошибки достигают 75%. Почти такого же эффекта достигает и парное программирование. Поэтому взаимопомощь разработчиков внутри проекта является элементом парного программирования и позволяет выявить большую часть проблем еще до релиза. и если помощь одного разработчика другому в компании пресекается (я с таким сталкивался), то качество продукта реально страдает.
В таких языках программирования, например, как С#, если вы столкнулись с необходимостью протестировать private метод(кусочек внутренней логики) какого-нибудь класса, то у вас всегда есть 2 варианта:
— Реализовать этот метод как protected
— Вынести логику в отдельный внутренний(вложенный) класс
При этом клиенты изначального класса ничего не узнают об этих изменениях, и инкапсуляция будет сохранена.
А что делать в 1С?
Иногда бывают такие сложные функции, что тестировать их через перебор всех граничных состояний входов и выходов просто невозможно.
(3) Alien_job, серверные процедуры модулей форм можно вызывать даже если они не экспортные.
(22) Armando, спасибо за подсказку.
Неожиданное поведение. Проверил, это действительно работает
(22) Armando, к сожалению, разработчики платформы уже в курсе об этом лайфхаке и обещали убрать в скором времени. (Надеюсь только для обработки ОписаниеОповещения)
(24) pumbaE, они не только в курсе, они даже на ИТС об этом написали, что надо учитывать эту особенность, и быть предельно осмотрительным.
(24) pumbaE, где обещали? Есть ссылка на тему на партнёрский?
(24) pumbaE, нашел на ИТС статью
(26) Armando, не совсем обещали, но надеяться на это не стоит.
(26) (28) Я даже статью на инфостарт писал об этом баге, но ее не приняли.
Пришлось на хабр выложить 🙂