[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: (2) Тестирование Software
SlavaFr
UnitTest (продолжение темы: http://phpforum.ru/index.php?showtopic=70546 )


Задача UnitTesta это тестирование кассов, методов, функций и модулей изолированно от других участков кода.

1) Мы создаем ряд критериев и условий, на основании которых мы можем судить о правильности выполнения определенного метода или функции.
2) Мы пытаемся сделать тесты так, чтоб доказать ожидаемое поведение наших функций, а так же пытаемся спровоцировать возникновения ошибки.
Меня попросили не показывать пример с калькулаторм и по этому я решил взять для примера обычную функцию пхп
например chr http://de3.php.net/manual/ru/function.chr.php
Из описания функции :
string chr ( int $ascii )


Вопросы которые я должен себе задать как человек тестирующий эту функцию:
Что я ожидаю от этой функции?
Является ли ретурн string и состоит ли он из одной буквы?
$ascii говорит о том, что ожидается число до 255
Что я ожидаю от этой функции если число будет более чем 255?
Что я ожидаю в случае если я пердам негативное число?
Что я ожидаю в случае если вместо integera будет передан другой тип?

После того, когда я выяснил, что я во всех этих случаях от функции ожидаю, я начинаю проверять все эти случаи на конкретные результаты.
К примеру задав число = 65 получится ли "А"
Задав к примеру число большее чем 255 или негативное будет ли брошена Exception? (чего не происходит)
И так далее.
То есть я пытаюсь тестировать функцию на определенное ожидаемое значение и опровергаю или доказываю таким образом правильность ее исполнения.

При наличии ошибок требуется изменить свои ожидания к функции или же изменить функцию так, чтоб она соответствовала нашим ожиданиям(правильный подход).

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

Преимущества при исправлении ошибок:
Если в будущем выяснится, что функция имеет ошибку, то нам будет не сложно доказать то, что мы эту ошибку починили, а также застраховаться от побочных явлений нашего исправления.
Для этого мы пишем еще один тест который подтверждает, что ошибка больше не происходит и запустить его вместе со старыми тестами проверив таким образом не только наше последнее исправление, но и не изменилось ли ожидаемое поведение которое мы тестировали раньше.
Уже ради этого преимущества стоит писать тесты, потому, что время на тестирование а так же проверка всех первоначально заложенных технических требований к функции при исправлении занимает немыслимое количество времени. Я работаю в большой группе программистов и из собственного опыта видел, как исправление ошибок в коде который не имел тестирования, приводили к возникновению новых ошибок и так продолжалось просто без конца и края пока мы заново не пересмотрели все требования, написали на эти требования тесты а потом сделали refactoring кода.

Там где делаются серьезные проекты вопроса "нужно ли тестирование" не существует, так как код без тестов просто запрещено добавлять в проект.
Я не хочу дальше специально говорить о пользе тестирования, так как я не являюсь в этой области экспертом. Я уверен, что я все преимущества перечислил :) и буду рад любым дискуссиям по этому поводу.

Когда тестировать?
Лучше всего после того как известно что делает функция и ясно что мы от нее ожидаем. То есть тест должен быть создан до того как будет написана сама функция. Такое программирование называют TDD(Test Driven Development) http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%...%BD%D0%B8%D0%B5
TDD относится на данный момент к лучшей практике создания новых продуктов.


Чем тестировать?
Даже простые запросы с if которые тестируют результаты функций или просто вызовы функции не вызывающие ошибок гораздо лучше чем не иметь не каких тестов, но зная, что уже имеются различные фрамеворки которые только для этих целей и созданы, было бы не правильно их не использовать.

список найденных фрамеворков для тестирования в PHP:
  • http://www.phpunit.de/manual/current/en/index.html
  • http://simpletest.org/en/start-testing.html
  • http://php-unit-test.batcave.net/
  • http://trac.symfony-project.org/browser/tools/lime/trunk
  • http://ojesunit.blogspot.de/2008/06/ojes-ultimate-unit-test.html Documentation Driven Testing :)
  • http://code.google.com/p/snaptest/
  • http://www.enhance-php.com/ интересный Mock и имеет code coverage
  • https://github.com/atoum/atoum
  • https://github.com/jamm/Tester
  • https://github.com/ptrofimov/phpinlinetest
Я пользуюсь PHPUnit и хочу приводить примеры именно с ним.
PHPUnit имеет:
1) Codecoverage( показывает на сколько код был покрыт тестами),
2) Помощь при создании Объектов симулирующих поведение уже созданных классов (Mock)
3) Помощь при создании тестов из класса.
4) Помощь при создании классов из тестов.

На тот момент, когда мы решили пользоваться PHPUnit он являлся более продвинутым чем другие библиотеки и показывал тенденцию в своем дальнейшем развитие. Это повлияло на наше решение использовать именно PHPUnit.

Для тех, кто желает в дальнейших статьях по тестированию опробовать код на собственной практике предлагаю инсталлировать PEAR и PHPUnit

http://pear.php.net/manual/ru/installation.php
http://pear.phpunit.de/

Продолжение http://phpforum.ru/index.php?act=ST&f=30&t=71385

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

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.