1) з/п может превышать 3$/мес, но учитывайте, что это "грязная" з/п, с который вы еще минимум 10% отдадите за налоги/комиссии/итд. А все это дело вам придется платить, ибо "в черную" вы не сможете физически работать (любой банк обяжет вас проходить валютный контроль).
2) з/п может превышать 3$/мес, если вы найдете достойную работу, и у вас имеются скиллы минимум на senjor-разраба с 6-ти летним серьезным enterprise-опытом.
3) в 95% случаев все, что вы найдете, будет аналогом фриланса. Именно работа по контракту - это единицы, и только конторы, которые сознательно работаю с сотрудниками из СНГ (например, VirtualHealth).
4) интервью - это рандом, как повезет.
5) вы можете найти много контор забугорных, которые охотно с вами при наличии внятного аглицкого и должной квалификации захотят работать, но... при условии релокации (да, с этим без проблем помогут, куда захотите: Бельгия, Нидерланды, Германия, итд).

Удаленка - до сих пор не особо любимый работодателями формат взаимодействия с сотрудниками, что у нас, в РФ, что за бугром (я именно про fulltime работу).

Поторопились с выводом.
Я ИП работаю уже 5-й год. Да, налоги плачу. Да, акты есть. Но крупным работодателям это на руку, и им лучше с ИП работать, чем в "черную". Конкретно я сейчас работаю на забугорную контору, с которой взаимодействие без ИП было бы невозможно.
Не хотите отчетности? Покупайте патент: никаких налогов и деклараций - только в ПФР платить фиксированную сумму (раз в год). И да, если захотите креди/ипотеку/итд, то без ИП вам ничего не дадут, ибо вы просто подтвердить доход не сможете (не будете же вы 13% НДФЛ уплачивать ежегодно).
Если же вы именно фрилансер со всеми вытекающими, то тогда, конечно, нет смысла.

Непонятно, что вы хотели получить в ответ, ибо не задали четкого вопроса.

Во-первых, вы, конечно, "удачно" выбрали Yii первой версии в качестве примера. Эта фреймворка не очень приспособлена для изготовления "тестопригодного" кода, ибо содержит на всех стадиях функционирования большое количество "магии". Не верите? Попробуйте что-то наваять на базе CActiveRecord и запилить юнит-тесты. У вас получится что угодно, но не то, что надо.
Самый главный аспект юнит-тестирования состоит в том, что один тест (метод класса-теста) должен решать строго одну задачу, а не проверять в фоне целую подсистему.
На одном из своих проектов я решил эту проблему, написав целую свору заглушек.
Во-вторых, все зависит от задач. Грубо говоря, юнит-тесты проверяют код как есть. Следующий уровень тестов (не берусь его называть, ибо я их постоянно путаю) проверяет бизнес-сценарии. И самый высокий уровень проверяет все это дело в связке с внешними интерфейсами.
И в-третьих, один тест не должен включать код других тестов, ибо каждый тест должен быть изолирован, считая, что весь остальной код работает. Именно поэтому, когда вы пишете, например, тест для мелкой модельки, не нужно гонять работу с БД: считается, что вся подсистема взаимодействия с БД _работает_.

Да, и еще. Очень часто путают моки и стабы.
Стаб - это заглушка - код, который "глушит" выполнения другого. Цель заглушки - проверка того, _что_ возвращает объект в своей работе. В вашем случае нужен какой-то объект, который не позволит коду выполняться далее LoginForm::login(). Как это сделать? При статической типизации кода - никак. Нужна надстройка, которая будет динамически использовать данные объекты, чтобы их можно было заменить на стабы.
Мок - это надстройка над тестируемым объектом, целью которой является проверка того, _как_ работает объект внутри, именно поэтому моки всегда строятся на Reflection.

Вот, никогда не задумывался над этим.
Говоря о себе... Я не использую ни таймтрекеры, ни тайм-что-то-еще, ни фломастеры (тем более цветные), ни тетрадки, и тд, а так же не смотрю на других коллег. У меня такой склад ума: меня всякие "рисовалки", коллективное планирование и тд только отвлекают и утомляют. Возможно, из-за этого мне будет сложно что-то внятное посоветовать, но...
1. Работать, как можете. Не надо стремиться к звездам, ибо, если задатки есть, оно само проявится. Так у вас выработается правильная самооценка.
2. Читать литературу, умную, и не "С++ за месяц", а "Архитектура корпоративных приложений" и иже с ней. Так у вас появится теоретическая платформа для понимания как микро-архитектур, так и более серьезных вещей.
3. Наблюдать за собой, чтобы понять: в какие периоды суток вам наиболее комфортно работать (в какое время у вас наиболее высокая производительность), и какие факторы на это влияют. Так вы сможете планировать.
4. Не стремиться заучивать наизусть синтаксис и семантику языков, но знать какие-то общие вещи, а так же места, где можно быстро найти ответ. Так у вас появится свободное место в голове.

В общем, трудитесь, читайте литературу, и все будет хорошо.