PHP относится к популярным языкам программирования по причине быстрого изучения и возможности очень быстро создать скрипт соответствующий требованиям заказчика.
К сожалению именно этo преимущество PHP является его проклятьем. При решении быстрых и маленьких проблем, программный код являются часто не продуманным для расширения и изменения, а также являются часто монолитным.
В конечном итоге после нескольких поправок в коде и добавления парочки новых вещичек мы стоим перед скриптом в тысячу строк и понимаем, что если мы его сейчас не разложим по полочкам, то завтра будет проще написать все заново. Каждое изменение может вызвать ошибку в других местах и поиск ошибок занимает больше времени.
Эта проблема знакома не только начинающим, но и у опытным программистам, которые хотят произвести изменения или просто исправить ошибку даже в хорошо организованном коде.
И тут возникают проблемы!!!
Не попортим ли мы нашим изменением в одном участке кода, что то другое? Где еще употребляется эта функция или класс?
Сколько времени уйдет на то, чтоб проверить все ли работает как положено после нашего изменения?
Даже простая проверка формуляра затрачивает время и энергию, по тому, что нужно проверить все ли данные были записаны в ДБ.
Представьте себе изменение, которое может повлиять на поведение сложной программы практически во всех ее участках?
На определенном этапе развития softa вы дойдете до момента, когда проверка работоспособности вашего продукта занимает больше времени, чем его минимальное изменение. Потом это магическое минимальное изменение будет сопровождаться страхом того, что вы не в состоянии дать гарантии работоспособности продукта и наконец наступает последняя стадия, когда вы даже не сможете описать, что и где собственно нужно точно тестировать чтоб все проверить.
Единственное, что вас в этом случае может спасти, это тестирование всего вашего продукта и делать это автоматизированно.
Вы делаете изменение и запустив тесты получаете подтверждение тому, что с большой вероятностью (100% не существует) не чего не поломали.

Основные виды тестирования
1) Unit test: Здесь мы тестируем конкретный модуль, класс или функцию.
Этот тест делается как можно не зависящим от других элементов и каждый тестируемый элемент должен тестироваться изолированно от других.
Именно запуск этих тестов можно проще всего автоматизировать.

2) Integration testing: Здесь мы тестируем взаимную работу модулей и можем проверить работает ли модули и компоненты между собой правильно.

3) System testing: Здесь мы проверяем работает ли вся система так, как она должна работать соответственно заранее описанным требованиям.

4)Acceptance testing: Заключительный тест который проводит заказчик или группа людей тестирующих основные функции в ручную (QA (Quality assurance)) проверяя правильность требований.

Тестирование стоит время и денег. Тестирование занимает около 70% времени программирования, но это себя окупает в будущем и именно по этому тестирование оправдывает себя также финансово.
1) Протестированные классы и модули можно использовать без риска в других проектах.
2) Время для изменения и дополнения актуального продукта а так же refactoring(реорганизация кода) и bug fixing(исправление ошибок) занимает гораздо меньше времени, так как имеется возможность быстро проверить работу всей системы.

Если вам стала понятна необходимость тестирования, то в следующий раз хочу затронуть Unit test посредством PHPUnit. Также немаловажно поговорить о том, как сделать код таким, чтоб его можно было тестировать.


От: буду рад любому вопросу и критике ( включая мой ухудшающийся со временем русский язык)

Продолжение: http://phpforum.ru/index.php?showtopic=70671

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

Отличная тема! Продолжай!

_____________
Свои мозги еще никто не отменял.
Телепатов нету.

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

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

@invis1ble я хочу в любом случае простые примеры, а также примеры с Mock-объектами привести. Также мне хотелось бы привести примеры TDD (test-driven development) где тесты пишутся до того, как начинается код. Далее хочу привести примеры автоматического создания шаблона тестюнит-класса из уже готового классов. Особенно я хочу затронуть тему того, как должен вообще выглядить код, чтоб его можно было тестировать и как его правильно подготовить для этой цели.
К стате насчет "калькулятора", каие предложения будут у тебя? В любом случае мы должны отдавать себе отчет, что примеры должны быть такими, чтоб люди концентрировались на тестирование а не на гениальную сущность класса.

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

Как показывает опыт, забивают на эти Unit тесты большинство даже уважаемых кампаний по разработке web приложений, в пользу скорости и корявости.
Пообещали заказчику сделать проект за месяц, заказчик обрадовался. Сломя голову собирают проект из того что было, т-к сроки не позволяют не то что оттестировать, а даже просто написать проект нормально.
А потом плюют в сторону программистов, мог криворукие, а на самом деле во всем виновато амбициозное начальство. Печалька....

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

SlavaFr

Самый главный фактор легкого написания тестов, это первоначально грамотная архитектура классов и приложения в целом. Т.к иногда очень муторно и долго мочить цепочу классов, только для того, чтобы дойти до своего метода..))

Вот от этого быстро пропадает желание писать какие либо тесты. Хотя функциональные тесты еще можно накатать)

Oт перечисленных проблем приемущества тестирования и недостатки нетестирования не меняются. Нас наняли как специалистов, для решания проблемы и мы должен ясно и четко сказать нашу позицию и объяснить людям на палцах какой риск возникает при создании не проверенного softa. Начальник или клиент должены сами потом решать, что им лучше, быстрые деньги, быстрый прэкт, или выгодные длительные отношения, или доброе имя. Пусть так же начальник не удевляется, что его обещание по поводу новго наварота вдруг займет гораздо больше времени чем он пообещал клиенту и что лечение одного bug будет одновременно пораждать новый bug. Главное мы должны об это громко и ясно заявить.

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

SlavaFr
у меня такое очущение что не работает в it сегменте) ну или в какой красочной компании... а может это я работаю (л) только в тех где говорят следующее: надо быстро и качественно. И при попытке что то объяснить тебе говорят, да мы понимаем, а после этого тоже самое: надо быстро и качественно)

Joker я в общей сложности более 5 лет работал там, где качество имело большее значение чем количество и уже 2 раз работаю с софтом, который был куплен уже горовым. Так вот, цена софта зависет сильно от его качества а одним из самх веских покатателей качества является наличем тестов.

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

а тебе там выдели времена отдельно на написание тестов?) чо за компания?)

У кого PEAR не встаёт на php5.3 нужно править go-pear.bat

@ECHO OFF
set PHP_BIN=php.exe
%PHP_BIN% -d output_buffering=0 -d phar.require_hash=0 PEAR\go-pear.phar
pause

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

всё а на установке PHPunit - устал. не знает консоль что такое pear и всё.

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker