latteo

Аналитически.

Я нашёл этому поистине чудесное доказательство, но поле ввода слишком узко для него. (C) Ферма.

Если проект простой, то конечно удобнее из клиентского приложения вызывать SELECT, UPDATE и INSERT.
Но как только проект становится достаточно большим, или накладываются дополнительные ограничения на безопасность, то удобнее вынести часть бизнес-логики на сервер. В данном случае - на хранимые процедуры.
Плюсы следующие:
1. Хранимые процедуры и клиентское приложения могут писать разные люди (команды), с разной подготовкой. Хранимые процедуры - боле опытные, клиентское приложение - более неопытные.
2. Хранимые процедуры могут обеспечить дополнительный уровень безопасности. Часть проверочной логики может быть реализовано на сервере. И клиентское ПО даже изменив или подделав вызовы не получит не принадлежащие им данные. Если вся логика приложения реализована на клиенте, то злоумышленник может переписать запросы и получить не принадлежащие ему данные. Помимо этого от клиентского ПО скрывается структура БД.
3. Хранимые процедуры, как неинтерактивные модули, проще отлаживать и тестировать в автоматическом режиме.
4. Написанные хранимки меньше, чем клиентское ПО, подвержены изменениям в ходе эволюции и активно повторно используются в разных клиентских модулях.

Можно. Если не запускать ничего — то зависит от версии Windows и стоящих на ней апдейтов.
7+ вроде научилась не запускать ничего в DLL, чтобы подгрузить оттуда иконки, и не делать автозапуска ни для чего, кроме CD.
В общем, советую для таких винтов обновлённую 7+ и двухпанельный коммандер, а не Проводник. Мало ли какой эксплойт попадётся, чтобы заразить комп через Проводник, а под коммандеры пока такого не пишут — да и путей подобного заражения меньше.
UPD. И исполняемый файл сложнее принять за каталог на двухпанельном коммандере.
UPD2. После этого тем же коммандером перетряхните скопированные каталоги, чтобы убедиться, что там законные файлы, а не исполняемые. После чего можно пользоваться даже Проводником — вероятность заразиться мизерна. Если там «левые» документы (DOC, PDF и прочее, что часто эксплойтят) — советую прогнать скопированное на проге типа CureIt.

методично, всерьёз и надолго погрузиться в тему

Погружайся)) Методичнее некуда)

Не стоит смешивать модульные тесты и интеграционные (или функциональные). Цель модульных тестов проверить работу одного модуля (класса, например). В этом случае все его зависимости мокаются. Целью интеграционных тестов является проверка взаимодействия цепочки модулей (сервисов, с БД и т.п.) друг с другом.

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

То есть правильно было бы сформулировать вопрос таким образом: "какой процент покрытия модульными тестами будет достаточным для моего кода?" Обычно останавливаются где-то на 70-80%

Также очевидно, что 100% работающих модульных тестов не гарантирует работу интеграционных тестов или функциональных. Поэтому необходимо писать и те и другие.

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

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

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

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

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

У mindmup.com исходники открыты вроде бы как https://github.com/mindmup/mapjs
Аналоги
https://www.npmjs.com/package/mindmaps
https://github.com/d3/d3/wiki/Gallery

пример 2 и только
Обьясню
Например, SomeClass - сервис логгирования.
Тогда сделаем ему интерфейс, создадим 2 подтипа - логер на файлах и в БД.
Итого 1 интерфейс, 2 класса реализации.
Параметры метода описаны в интерфейсе..
Вот и имеем, что метод будет вызван с конкретным аргументом...
В других случаях не понятно поведение подклассов, которые будут это реализовать.. А именно в плане того, что должен делать setItem в 1 случае, и ессно интерфейсы не могут описывать конструкторы как в примере 3...
В итое имеем, что можно легко заменить объект другим объектом ТОЛЬКО в примере 2.
Насчет геттеров - имхо, лучше создавать приватные свойства и геттер+сеттер
Т.к. на больших проектах чаще всего получается лапша, да и в плане многопоточности, и опять же-интерфейсов -просто свойства не есть хорошо...

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

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

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

Функциональное тестирование проверяет соотвествие требованиям проекта. Например, при нажатии кнопки Удалить появляется окно подтверждение с текстом "Вы уверены", затем при нажатии кнопки "Да", запись удаляется из БД и пользователю выводится сообщение "Запись успешно удалена!".

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

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

Тестирование контроллеров и моделей по отдельности - это юнит-тесты.
Тестирование связки контроллер-модель - это интеграционное тестирование.
Тестрование работы сайта целиком с помощью того же Selenium и т.п. - это функциональное тестирование.

Если у Вас один-три сервера, скорей всего, Docker Вам не нужен. В этом случае для управления конфигурацией лучше используйте ansible.

Потребность в Docker возникает либо в случае когда нужно расшарать одно окружение на множество машин, например, у меня и моих коллег сейчас девелоперское окружение(php + apache + mysql + redis) крутиться на контейнерах. Второй пример - нужно настроить динамическое горизонтальное масштабирование. Этот вариант Вам нужно рассматривать, только если Вы используйте AWS или что-то подобное.

В целом, docker / ansible / chef / puppet и т.п. Вам нужны только в случае, если нужно шарить одно окружение на разные машины, причем часто, с уверенностью что оно везде одно. Другого примера использования придумать не могу.