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