Виктор Выскребенцев: > 1. С чьей стороны инициировать обновление\импорт - от приложения или от опенкарта?
я бы делал выгрузку со стороны opencard, сомневаюсь, что на БД сервере необходимо что либо знать о нем.
> 2. Как именно добавлять? ...
Здесь нет правильного ответа. Пишите как удобней, но не забывайте про обязательную проверку данных полученных опенкартом.
Mikhail Osher Шта?)) Про фаталы это просто первый пришедший пример в голову.
>> это вам по рукам надо веником бить, ибо коряво код пишете.
Вы не знаете как я пишу код, не стоит делать таких заявлений))
Express777 Мне жаль вас расстраивать, но git и github - это принципиально разные вещи. git - децентрализованная vcs, github - соц. сеть + хостинг проектов на базе git. Есть еще gitlab))
Конкретно по БД: обычно используется механизм миграций, который отличается, в зависимости от языка, фреймворка и БД.
Uran_90 > но не всех же классов
При стремлении покрыть код тестами - да нужно проверять все классы и все методы. Черный ящик стоит проверять после диплоя например, а белый - на тестовом окружении.
Книги нет. То, что вы спрашиваете - алгоритм выбора того, что необходимо тестировать. Он полностью зависит от конкретного проекта, если это эл. магазин например - в первую очередь тестируется система оплаты и система товаров. Если это сайт-визитка - система вывода и шаблонизации. Если это БД - целостность фалов и отладка в случае сборев. Если это кэш система - бенчмарки производительности и целостности.
Вот пример либы, добавляющей несколько адаптеров логов к yii2 https://github.com/index0h/yii2-log/tree/master/te... . Здесь покрытие 90%, при этом проверяется каждый из адаптеорв на валидные входные данные и не валидные. Это и есть unit тесты. Их задача проверить, что обработка внутри тестируемого класса выполняется верно.
Еще раз, unit тесты - это тесты классов. У тебя есть класс User с методами register, login и logout. Нужно написать кучу проверочных тестов для каждлого из этих методов.
базовые принципы unit тестов следующие: есть метод А(a, b) возвращающий z.
необходимо написать методы, которые будут:
* вводить правильные данные a, b и проверять правильность результата z
* вводить правильные данные a, и не правильные b, по идее должна быть исключительная ситуация, ее нужно отловить.
* введить не правильные данные a, b в этой ситуации по идее тоже должна быть исключительная ситуация
* введить не правильные данные a, и правильные b, по идее должна быть исключительная ситуация, ее нужно отловить.
* + еще отдельные проверки для спец кейсов использования метода.
В случае тестов черного ящика: проверяется только внешний интерфейс модуля / класса, в случае белого ящика - проверяется каждый публичный метод и часть (либо все) приватные / защищенные.
Александр Верно, но в этой ситуации узким горлышком системы будет как раз этот валидатор (с точки зрения безопасности). Есть например https://github.com/Respect/Validation довольно неплохое решение.
Сергей Протько Ну вот например pastebin.com/J8hXFNmY с эстетической точки зрения оно конечно не очень, но помогает довольно быстро искать ошибки + взломать такой код будет сложнее.
+1 Дополню:
scrutinizer не всегда правильно оценивает код. Например существует практика для защищенного кода: выполнять проверки входных данных на уровне функции, а не на уровне модуля, как правило - это будет оцениваться phpcpd как копипаст, но для данного кейса это необходимо.
> Не легче было написать по делу, нежели тратить свое время на искусное литье воды?
Я написал по делу, причем без воды. Не существует даже единой трактовки слова "парсер". Это может быть полностью клиентское приложение, это может быть клиент-серверное приложение. С поддержкой js, или без. С системой рендеринга и формирования DOM, или без. Одностроничный, или более продвинутый аля бот. Вы просто по telnet попробуйте авторизироваться, например в vk (без языков, напрямую через HTTP).
> Какой конкретно язык?
Это можно сделать на: php / js / ruby / python / golang / rust / perl / ... Это самый конкретный ответ на ваш вопрос. Но сам язык вам ничего не даст без опыта. Не существует книг "Как написать парсер за 21 день".
Начальную точку отправки я вам четко сформулировал: основы работы сети, html, css. Грубо говоря, что бы написать хотя бы простенький парсер нужно уметь делать сайты.
Проекты кириллическими названиями в большинстве "ну такое"... увы, и ах.
> те как я понял проекты доступны в инете для всех?
если вы настроете проект, как открытый и публичный - да, в противном случае - нет. У них есть И облачное решение и локально установить можно.
