И вот никак не могу понять, зачем писать ООП классы для, например, изменения группы пользователя, когда это делается 1 строчкой?
Пишутся не классы. Пишутся объекты. И объект пишется не под изменение какого-либо свойства. Объект описывает пользователя всевозможными свойствами и методами. И в эту обёртку помещается метод изменения группы конкретного пользователя.
//Типо ООП
$user->delete;
//Типо функция процедурная
delete($user);
//Один хрен же, нет?
Так то оно один хрен, да только не один. Абстрактный пример.
У вас, кроме $user, есть еще $group, $catalogue, $order и еще с десяток объектов, с которые вам нужно будет работать. Теперь представим, что вам нужно будет удалить объекты. В ооп стиле вам нужно будет просто вызвать метод ->delete для каждого объекта. А в процедурном вы будете писать 10 функций delete с разными названиями? Или одна, но внутри вы будете писать 10 проверок, что бы понять, какие данные к вам пришли и как их правильно обработать. А если таких объектов будет 100?
В ооп есть свои + и -. И ни в коем случае ООП не является панацеей ото всех бед. Где-то процедурный стиль выиграет, где-то ооп. Как мне кажется, профессионал обязан понимать, когда и зачем использовать ту или иную технику или инструмент.
UPDнужно проводить тесты над кодом
И вы, вероятно, путаете понятия "тестировщик" и
TDD