Только вот например, если ее использовать для хранения документации по проектам, каким образом можно организовать совместный доступ и редактирование? Можно ли как-то с SVN (Git, Mercurial) интегрировать?
«Необходимость тестировать приватные методы — проблема в архитектуре»? В статье нет слова «необходимо», там написано «можно».
Если вам нужно отрефакторить один класс, вы же не бросаетесь покрывать тестами весь проект. Так почему при рефакторинге одного метода не ограничиться тестами только для этого метода?
1. Да, только простые тесты.
2. assert в коде принципиально отличается от inline-теста: первый будет проверен уже при выполнении скрипта, тесты же можно прогнать заранее.
Если модульные тесты покрывают весь функционал класса, inline-тесты теряют свою практическую ценность, так как по сути дублируют существующие тесты, НО остается еще ценность их как наглядной документации.
Если модульные тесты НЕ покрывают весь функционал класса, inline-тесты имеют свою нишу, так как их проще добавить.
Я считаю, что нужно тестировать поведение (интерфейс), а не реализацию, которая завтра может поменяться.
Постойте, это как посмотреть. Unit-тесты как раз и тестируют реализацию. А вот функциональные — тестируют интерфейс. :)
Я так подумал, получается просто другой уровень — другая глубина проникновения тестов. Unit-тесты тестируют блоки всего приложения. Inline-тесты могут тестировать блоки, из которых состоят первые блоки.
В том-то и причина, что по моим убеждениям «код-то дожен быть протестирован» неприменимо к приватным методам.
Приватные методы — это не код? (вопрос риторический, прошу вас, не отвечайте на него)
Все верно: если метода нет, то и тест для него не нужен. Inline-тесты тестируют не систему, а конкретные методы, к которым привязаны. Заметьте, что это не замена unit-тестов, а лишь их дополнение.
Но в защиту token_get_all хочу сказать, что:
1. Эффективнее по ресурсам: обработка файлов выполняется по очереди, для Reflection пришлось бы сделать 100500 инклюдов.
2. Быстрее: тут только парсинг скрипта, а в случае Reflection еще и выполнение всего кода.
3. Если в разных файлах будет функция или класс с одним и тем же названием, то при использовании инклюдов будет конфликт имен.
Только вот например, если ее использовать для хранения документации по проектам, каким образом можно организовать совместный доступ и редактирование? Можно ли как-то с SVN (Git, Mercurial) интегрировать?
Если вам нужно отрефакторить один класс, вы же не бросаетесь покрывать тестами весь проект. Так почему при рефакторинге одного метода не ограничиться тестами только для этого метода?
2. assert в коде принципиально отличается от inline-теста: первый будет проверен уже при выполнении скрипта, тесты же можно прогнать заранее.
Если модульные тесты НЕ покрывают весь функционал класса, inline-тесты имеют свою нишу, так как их проще добавить.
Постойте, это как посмотреть. Unit-тесты как раз и тестируют реализацию. А вот функциональные — тестируют интерфейс. :)
Я так подумал, получается просто другой уровень — другая глубина проникновения тестов. Unit-тесты тестируют блоки всего приложения. Inline-тесты могут тестировать блоки, из которых состоят первые блоки.
Приватные методы — это не код? (вопрос риторический, прошу вас, не отвечайте на него)
Но на мой взгляд, вот это:
* php> factorial(0)
* 1
хуже, чем это:
* @assert factorial(0) == 1
1. Эффективнее по ресурсам: обработка файлов выполняется по очереди, для Reflection пришлось бы сделать 100500 инклюдов.
2. Быстрее: тут только парсинг скрипта, а в случае Reflection еще и выполнение всего кода.
3. Если в разных файлах будет функция или класс с одним и тем же названием, то при использовании инклюдов будет конфликт имен.
Если вы имеете в виду PHPUnit, то да, inline тесты по сути дела дополняют его.