Извиняюсь. В следующий раз буду читать комментарии.

Вы наверное молодцы, и проект у вас замечательный. Но спамить то зачем?

Личное сообщение на Reformal.ru

Пользователь regular_user отправил Вам сообщение:

Предложение
Ребят! Меня достал уже позорный реформал на вашем сайте. Поставьте уже пиздатую обратную связь — copiny.com Нашел вам промокод даже на скидку для платных тарифов — webstudio Ссылка на их сайт: bit.ly/go_copiny

Лучше создать issue на github. Не факт, что Дмитрий читает этот пост.

Прозрачное кеширование можно организовать и софтово. С настройками исключений, «умным» управлением и прочими плюшками.

Вы про церковь или анонимусов?

А можно добавить к сетам famfamfam'овские?

Можно посмотреть в телефонах или машинах. Скорее всего что-то с «волнами» вокруг.

Да, у Юсуке нашел. Этого набора я раньше не находил, использовал silk от famfamfam.
Две стрелки в разных направлениях? Почему то линию с двумя стрелками не все понимают.

Нигде не могу найти:
— работа с узлами деревьев (CRUD). У вас тоже только само дерево.
— «поменять местами»

Спасибо за набор!

А в чем проблема. Код создания пользователя есть, код логина — тоже. Остается объединить. В идеале:

function createAndLoginUser($params = ...)
{
  $auth_manager = new AuthManager($this->createUser($params));
  $auth_manager->login();
}

У нас, кстати, loginByUser используется повсеместно. Администратор может залогиниться под любым пользователем. Помогает при расследовании баг-репортов.

А вот этого не должно быть. С какими частями дублируется код? С контроллерами?

Ну да, фиксация состояия, я уже выше согласился))

В такой же ситуации я начинал с пустой(ну кроме словарей) базой, и прошелся по всем прецедентам, логгируя связки action -> {sql-запросы}. После недолгой медитации над результатами, удалось узнать возможные side-эффекты от изменений. Собственно отсюда и были получены связки action'ов, которые можно тестировать друг другом.

И все равно я не понимаю зачем эта библиотека, если мы оба говорим о слепках :)
Равное тестируют, либо равным, либо более низкоуровневым. Иметь еще одну библиотеку для работы с sql? Плюсы? Смены БД на непонятном legacy-коде не будет. Банальное неудобство mysql_*? Есть PDO. Дампы проще снимать и применять в SQL. Да и читается он лучше, чем XML.

Как то так?

function createPersonWithJob($finance)
{
  $person = $this->createPerson($dob = null, $with_passport = false, $name = null, $finance);
  return $person;
}

Вы же сами говорили о проверках умножения, через деление. Находим проверочное действие, глобально отметаем представление, подменой Smarty-объекта на свой, тестируем связку действий. Интерфейсов как минимум два — http и смарти. Контроль над базой не даст протестировать чтение, только create/update/delete.

А какие решения? Вся суть паттерна: не хочешь дублирования бизнес-правил в снимке базы и коде — используй бизнес код для наполнения данных. Ну можно генераторы строк туда прекрутить. Генераторы файлов. А в остальном то все руками пишется.

Это же веб, т.е. уже не полностью монолит. Я бы начинал сверху, с уровня контроллеров/экшенов и спускался вниз, выделяя слои. В любом случае — контроль над базой им особенно ничего не даст, кроме документирования работы с базой текущего кода.
Хотя согласен, это будет полезно, если переписывать код целыми модулями. Если же править итерационно, то не вижу плюсов.

С таким же успехом можно сказать, что РНР сообщество поняло это 5 лет назад — wiki.agiledev.ru/doku.php?do=revisions&id=tdd:object_mother

Вам важен факт факт, что она работает, или как столбцы называются? Зачем вводить зависимость от SQL?

Лучше тем, что тестируется поведение, а не внутренняя реализация. Ну и отсутствием лишней библиотеки.