Юнит-тестирование в PHP

В моем коменте habrahabr.ru/blogs/php/56289/#comment_1514072 есть ссылка где показана работа с Zend_Test

Плохая новость в том, что большинство решения для работы с БД, слабо поддаются мокингу, :) поскольку сами созданы без использование этих принципов. Некоторые современные технологии для работы с БД(ORM), приближают нас к этому. Но пока все еще в стадии развития, хотя самому TDD уже предостаточно времени.
Скажем так. TDD выходит из стадии испытания и начинает использоваться в индустрии(asp net mvc полностью построен на нем)

юнит тесты не увеличивают качество кода! Они просто позволяют его в будущем дешевле изменять
bishop-it.ru/?p=119

Например, Michael Feathers в своей книге Working Effectively with Legacy Code не призывает покрывать все 100% кода тестами. Мало того, он даже не призывает всегда покрывать тестами код, который вы собираетесь изменять. Он призывает думать. Каждый раз делать осознанный выбор — нужны ли вам в данном месте юнит тесты или нет. Всем советую купить и прочитать эту его книгу. Эта книга — лучшее описание теории и практики написания юнит тестов, что я встречал. Причем именно с точки зрения практики — большая часть книги посвящена описанию стандартных приемов работы со старым кодом. А сам автор имеет огромный практический опыт по улучшению legacy кода.

Вы не тратите время на обдумывание кода (все поведение обдумывается на этапе написания тестов, код пишется только, чтобы их выполнить)

Есть путь менее правильный, но более быстрый — тестирование осуществляется вручную с консоли, а потом результаты просто копи-пастятся в доктест. Это не даёт гибкости в том плане, что удобны лишь проверки на полное равенство вывода эталонному, но зато накладных расходов на написание таких тестов нет. Поясню примером:

Захотелось мне написать функцию для разложения числа на простые множители. Создаю файлик my.py со следующим кодом:

def f(x):
        assert x > 1
        i = 2
        while i <= x:
                if x % i == 0:
                        x /= i
                        yield i
                else:
                        i += 1

Как проще и быстрее тестировать такое? Правильно, в консоли. Запускаю с тестовыми параметрами и смотрю результат:

>>> from my import f
>>> list(f(1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "my.py", line 8, in f
    assert x > 1
AssertionError
>>> list(f(3))
[3]
>>> list(f(4))
[2, 2]
>>> list(f(60))
[2, 2, 3, 5]

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

def f(x):
        '''
        >>> list(f(1))
        Traceback (most recent call last):
          File "<stdin>", line 1, in <module>
          File "my.py", line 8, in f
            assert x > 1
        AssertionError
        >>> list(f(3))
        [3]
        >>> list(f(4))
        [2, 2]
        >>> list(f(60))
        [2, 2, 3, 5]
        >>>
        '''
        assert x > 1
        i = 2
        while i <= x:
                if x % i == 0:
                        x /= i
                        yield i
                else:
                        i += 1

Теперь как-то надо уметь этот тест запускать. Простейший способ — добавить в конец файла немножко кода для вызова теста текущего модуля при загрузке этого модуля первым:

if __name__ == '__main__':
        import doctest
        doctest.testmod()

Запускаем:
$ python my.py
$


Вывод пустой — всё в порядке.

Сэмулируем теперь ошибку логики, поправив тест:

$ python my.py
*******************
File "my.py", line 13, in __main__.f
Failed example:
    list(f(60))
Expected:
    [2, 2, 3, 6]
Got:
    [2, 2, 3, 5]
*******************
1 items had failures:
   1 of   4 in __main__.f
***Test Failed*** 1 failures.

Кто-то мог заметить, что в трэйсбэке исключения зашит номер строки — это мелочи, фрэймворк корректно обрабатывает их отличия от эталона в тесте.

Итого — тесты имеются, а накладных расходов — минимум.

В рамках одного проекта — или везде или нигде

Не соглашусь. В рамках большого проекта начать писать тесты на всё сразу — не хватит сил, не писать по-прежнему — неразумно, потому тесты пишутся на новый, изменившийся функционал и на обнаруженные ошибки. Через некоторое время можно не переживать о том, что значительная часть кода не покрыта тестами — значит, этот код относительно стабилен.

Не только для команд. Один человек вполне может это использовать, как и команда.
Просто для команд это куда более критично, когда над одним и тем же кодом работает больше одного человека.

Западники уже реализуют подобные механизмы. Collaborative Development Environments. У нас пока это все только из области фантастики. Хотя технически — вообще все легко.

Код проекта PHPUnit тестируется с помощью PHPUnit :)