itcoder

Не сложно. Есть только один автор, который понимает что пишет (т.к. является разработчиком 1С), это Радченко. Все начинают с его книг.

наверно самый простой способ это gearman.info
тем более если будете использовать php - то есть документация php.net/manual/ru/book.gearman.php
выйдет примерно так:
1. клиент раскидывает задачи воркерам - какие файлы им обрабатывать
2. воркеры получают список файлов из очереди и конвертируют их
2.1 если все вышло - шлют что задание выполнено (php.net/manual/ru/gearmanjob.sendcomplete.php)
2.2 если не получилось - шлют что не вышло (php.net/manual/ru/gearmanjob.sendfail.php)
по третьему вопросу - php.net/manual/ru/gearmanclient.setcompletecallback.php php.net/manual/ru/gearmanclient.setfailcallback.php - так можно будет на клиенте узнать сколько выполнено и провалено заданий

Как не смешно звучит, сам я эти книжки не читал, но, когда собирал подобную же вашей коллекцию, заметил, что их во многих местах рекомендовали безотносительно языка:
The-Art-Unit-Testing-examples
xUnit-Test-Patterns-Refactoring-Code
ActiveRecord нормально тестируется с помощью частичных моков. Даже запросы нормально тестируются, если их выносить в отдельный класс, а ActiveRecord::find() использовать только как фасад для получения инстанса нужно класса с запросами.
П.С. Поделитесь потом что нашли и что реально оказалось полезным.
П.П.С. А вот еще книжка хорошая The Clean Architecture in PHP. Она вроде бы не сложная, но очень хорошо описывает как можно IoC использовать, а это прямой путь к хорошим тестам.

Как вы тестируете статические методы?

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

В вашем же вопросе вы интересуетесь как мокать статические методы. И тут ответ тоже никак:

Please note that final, private and static methods cannot be stubbed or mocked. They are ignored by PHPUnit's test double functionality and retain their original behavior.

Есть правда еще мокери всякие и т.д.

DI именно в вашем случае не при чём. Это способ реализации, а не сама идея. Идея состоит в том, что вам нужно реализовать принцип инверсии зависимостей. То есть начать работать с интерфейсами, а не с конкретными реализациями.

Чтобы быть универсальным и переносимым, модуль не должен знать о моделях извне себя. Вместо этого он должен выражать свои требования в виде интерфейса, а внешние модели этот интерфейс должны реализовывать.

Для вашего примера делаем в модуле Article делаем интерфейсы:

interface ArticleInterface
{
    public function getTitle();
    public function getAuthor();
}

interface ArticleAuthorInterface
{
    public function getName();
    public function getID();
}

Далее в пределах модуля используем только интерфейсы, а не сами модели:

public function renderArticle(ArticleInterface $article)
{
    return $this->renderPartial('_article', [
         'author' => $article->getAuthor(), 
         'title' => $article->getTitle()
    ]);
}

Вне модуля нам придётся реализовать интерфейсы в моделях:

class Article extends ActiveRecord implements ArticleInterface
{
   // ...
}

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

Модульные, они же юнит тесты, предназначены для тестирования отдельных модулей/классов. Суть их в том, что мы тестируем поведение только одного класса за раз. Если класс ссылается на инстансы других классов - мы их мокаем. То есть подсовываем им фэйковый класс, который имеет тот же интерфейс, но внутри не реализациа методов, а проверка, вызывали ли метод, с каким аргументами, сколько раз вызывали и т.д. Так же методы мока могут возвращать стабы (заглушки), какие-то захардкоженные под какой-то кейс данные. То есть если мы пишем класс по работе с базой данных, сокет-сервер и т.д., нам стоит соединение с базой, сокеты и т.д. оборачивать в классы, что бы можно было потом подменить на моки это добро. Если у вас в юнит тестах идет реальная работа с файловой системой или что-либо в этом духе, то это уже попахивает интеграционными тестами. Подробнее можно почитать в документации к phpunit. Так же есть такая методология разработки как TDD, советую почитать "Экстримальное программирование" Кента Бэка в этом ключе.

Сразу хочу отметить что юнит тесты это хорошо, но вот только рядовой разработчик на PHP редко пишет что-то, что стоит покрывать юнит тестами. Времени на их поддержку нужно не мало, а требования у заказчиков частенько меняются. В итоге тесты начинают комментить и толку от них становится ноль. А вот если вы пишите компонент/библиотеку, то тут юнит тесты обязательны (ну... не то что бы, но желательны). Так что я бы на вашем месте сконцентрировал внимание на первом этапе на интеграционных и приемочных тестах.

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

Функциональное тестирование - это тестирования всего приложения в сборе. Если это REST API, то у нас через curl дергаются реальные методы, отправляются более менее реальные запросы и валидируются ответы. Если web-страничка, то это UI тесты с силениумом/phantom.js/zombi.js или, если нам не нужно еще и js тестить, просто curl + какой виртуальный браузер на том же php. Вообще по хорошему функциональные тесты не допускают никаких моков и т.д. но опять же если очень хочется то можно (опять же обращение к сторонним сервисам, контроля за которыми у нас нету).

Но реалии таковы, что UI тестами покрывать проект не слишком удобно. Вопервых UI может меняться, а поддерживать их так же нужно. Во вторых это скучно. В третьих тесты могут просто падать... вот взяли и упали. И потом начинается, так, тесты опять упали... что там упало? А, не страшно, можно релизить. Так же на больших проектах UI тесты отрабатывают долго, очень долго, некоторых их просто ночью гоняют. Толку от тестов при таком подходе не слишком много, ибо разработчику стоит знать о том что что-то сломалось как можно быстрее. А так он приходит, видит что тесты опять красные, чинит эти красные тесты, и запускает... ждет... проходит пол часа к примеру, и где-то в другом месте отвалилось... Короче сами понимаете.

Приемочное тестирование - по сути те же функциональные тесты, но подаются в контексте фича-спеков. Если вы работали когда-нибудь с QA отделом, то возможно слышали про такие штуки как acceptance criteria. То есть это тот чек лист, который должен проверить тестировщик что бы удостовериться что все хорошо. На основе этого чек листа можно написать функциональные тесты. Так же есть инструменты вроде Cucumber/Behat, которые позволяют писать спецификации в виде стэпов. В этом случае спецификации для этих инструментов могут писать QA а вы просто имплементите для них степы. То есть уменьшается прослойка между "acceptance criteria" и готовыми к выполнению тестов. Более того, стэпы можно реюзать, комбинировать, масса стэпов есть готовых, вам же необходимо только предоставить стэпы подготвалливающие систему (загрузка/генерация фикстур и т.д.). Короче лепота и удобно. Но медленнее интеграционных, зато не такие жесткие как функциональные, за счет этого их проще поддерживать. QA пишут спеку, реализуем тесты под эту спеку, пишем код под тесты, тесты зеленые - функционал готов.

Ну и есть еще всякие термины типа пирамида тестов и т.д. Мол лучше много юнит тестов, чуть поменьше интеграционных и мало функциональных. Тогда тесты выполняются быстрее, а покрывать все и вся функциональными тестами обычно перебор.

Ну и опять же, есть такая вещь как здравый смысл. Некоторые вещи скажем можно вообще забить и не покрывать тестами, некоторые стоит покрыть. Некоторые не полностью, некоторые с как можно большим покрытием.... Скажем тестить UI (именно как выглядит, где какой элемент) вообще бессмысленно. На это нужно куча ресурсов. Хотя может и есть проекты где это оправдано.

Короче почитайте про TDD и ATDD (можно и BDD затронуть, но тут не только от программиста зависит, менеджеры, заказчик или продукт-оунер тоже должны быть вовлечены, по сути этот подход хорошо работает в рамках продукта какого-то, на фрилансе и в аутсорсе редко можно встретить) , Continious Integration и Continious Delivery.

Скорее всего, у Вас UEFI/EFI. У меня такое было после установки линукса паралельно с Windows 7 на EFI. Grub просто не "подхватил" нужную запись.
В линуксе сделайте в терминале, пот рутом:

~# update-grub
~# reboot

Если не появился нужный пункт в списке систем, продолжаем. Выполните под рутом:

~# grub-probe --target=fs_uuid /boot/*/*/Microsoft/Boot/bootmgfw.efi
выводом будет Ваш идентификатор диска с виндой - выпишем его на бумагу

затем выполните (я использую vim, если не знакомы - любой другой консольный редактор:
~# vim /etc/grub.d/40_custom
и в самый конец допишите, после всех комментариев с новой строки:

menuentry "Windows x86_64 UEFI-GPT" {
insmod part_gpt
insmod fat
search --fs-uuid --no-floppy --set=root ВАШ_ИДЕНТИФИКАТОР_С_БУМАГИ
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

После этого выполните от рута:
~# update-grub
~# reboot

Profit!