jaxel

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

// Когда аргументы и их количество известно заранее
// Такой вариант мне кажется самым читабельным
// Оборачивать в фигурные скобки не обязательно
// Я это делаю всегда для того, чтобы было видно, что вызов динамический
$this->obj->{$function}($arg1, $arg2)

или

// Подходит как раз для описанного случая
// Аргументы могут быть любыми и передаются в виде массива
call_user_func_array([$this->obj, $function], [$arg1, $arg2]);

Во-первых, зачем использовать в Zend Framework 2 Doctrine ORM 2? Вся идея и фишка самого ZF2 в том, что это чистый PHP. Именно поэтому он лучше всех показывает себя в производительности. Наверное ещё и шаблонизатор какой то используете, например twig...
Во-вторых, если вы и вздумали использовать ORM, тогда используйте framework Symfony 2, там она очень хорошо интегрирована, и предоставляются всевозможные решение той или иной задачи.
В-третьих, насчёт организации, действительно сущность должна хранить защищённые/приватные свойства, и методы доступа к ним. Все операции над получением данных, вы можете поместить в директорию Repository, и поместить методы в класс EntityRepository (вместо Entity вставьте наименование вашей сущности), так это делается в SF2. На самом деле вы вольны в выборе организации, и вы можете делать так, как того пожелаете. Например можете поместить всё это дело либо в Model, или в Service. Разумеется можно просто это дело запихнуть в Controller, но так делать не следует.
Выбор за вами...

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

Модульные, они же юнит тесты, предназначены для тестирования отдельных модулей/классов. Суть их в том, что мы тестируем поведение только одного класса за раз. Если класс ссылается на инстансы других классов - мы их мокаем. То есть подсовываем им фэйковый класс, который имеет тот же интерфейс, но внутри не реализациа методов, а проверка, вызывали ли метод, с каким аргументами, сколько раз вызывали и т.д. Так же методы мока могут возвращать стабы (заглушки), какие-то захардкоженные под какой-то кейс данные. То есть если мы пишем класс по работе с базой данных, сокет-сервер и т.д., нам стоит соединение с базой, сокеты и т.д. оборачивать в классы, что бы можно было потом подменить на моки это добро. Если у вас в юнит тестах идет реальная работа с файловой системой или что-либо в этом духе, то это уже попахивает интеграционными тестами. Подробнее можно почитать в документации к 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.

Ответ на вопрос будет сильно зависеть от того, в каком направлении вы думаете развиваться.
Будет ли это сетевое программирование? Тогда это си, в основном.
Может быть, веб-программирование? Тогда тут могут быть php, javascript, python, ruby.
Захотите разрабатывать программы на десктоп? Вам нужны c# или java.
На мобильные платформы? тогда java и objective c (плюс swift).
Или податься в разработку игр? Тогда либо c++, либо с# (для Юнити - наверное, самой популярной платформе).
Хотите экзотики? Приглядитесь к функциональным языкам - Erlang и Haskell.
Разработка железа и драйверов для железа? тогда си (без плюсов) и ассемблер.
Определитесь, что вы хотите, потому что всё объять не получится. Выберите один (или два) направления и добейтесь хорошего уровня в нём. А потом вам будет уже легче двигаться дальше.

Мой совет - попробуйте изучать C# или Java (они во многом похожи) для софта, или Javascript и php/python для веб-приложений и сайтов.

Добавлю, что очень правильный совет дал @tsarevfs - помимо языка программирования, хороший программист должен знать несколько инструментов - и в первую очередь, это система контроля версий, например, git. Плюс юнит-тестирование (хотя это можно начать изучать позже, через годик-два). Плюс - нужно хорошо знать свою IDE, в которой работаете; не вздумайте работать в блокнотиках!

Ещё помимо практики нужно знать теорию - читайте Макконнелла, Фаулера, Мартина, Бека.
Подпишитесь на хабре на пару десятков хабов и регулярно читайте всё подряд. Через годик ваш уровень понимания статей сильно вырастет.

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

UPD. Важное дополнение из обсуждения в комментариях (спасибо @Argentum88 @Deerenaros )
Чтобы стать профессионалом и "востребованным программистом с нормальным заработком", нужно очень хорошо понимать внутреннее устройство тех систем (платформ, фреймворков), на которых идёт работа.
Для этого нужно заглядывать вглубь. Изучив различные мейнстрим-инструменты, посмотреть на аналогичные менее популярные системы. Изучать исходный код используемых open-source библиотек. Написать свою подобную систему. Для web - написать свою CMS (хотя бы базовую). Для десктоп-программ - попробовать программировать без навороченных библиотек, которые делают рутинную работу за программиста. Для разработчика игр - сделать простую игру на базовом инструментарии платформы, где всё придётся делать своими руками.
Всё это даст возможность проникнуться, почему всё делается именно так, даст понимание взаимосвязей разных частей программы.
А потом, осознав это, выбрать один из уже готовых инструментов, и продолжать писать на нём, уже обладая более глубоким его пониманием.