Eugene Tupikov
9 years ago
2 changed files with 81 additions and 4 deletions
@ -0,0 +1,76 @@ |
|||||||
|
Тестирование |
||||||
|
============ |
||||||
|
|
||||||
|
Тестирование является важной составляющей разработки программного обеспечения. Мы проводим тестирование непрерывно, осознаем мы это или нет. |
||||||
|
Например, когда мы пишем класс на языке PHP, мы может отлаживать его шаг за шагом или просто использовать `echo` или `die` для проверки, что |
||||||
|
реализация работает в соответствии с намеченным планом. В случае веб приложения, мы вводим некоторые тестовые данные в форму для того, чтобы |
||||||
|
убедиться, что страница взаимодействует с нами, как ожидается. |
||||||
|
|
||||||
|
Процесс тестирования может быть автоматизирован так, что каждый раз когда нам нужно что-то проверить, мы просто должны |
||||||
|
вызвать код, который сделает это за нас. Код, который проверяет, что результат совпадает с тем, что мы планировали, называется тестом, а процесс |
||||||
|
создания тестов и их последующего использования - автоматизированным тестированием, что и является главной темой данного раздела. |
||||||
|
|
||||||
|
|
||||||
|
Разработка с тестами |
||||||
|
-------------------- |
||||||
|
|
||||||
|
Разработка через тестирование (TDD) и разработка через поведение (BDD) - это подходы разработки программного обеспечения, в рамках которых |
||||||
|
поведение части кода или целая фича описывается в виде набора сценариев или тестов ДО написания фактического кода и только |
||||||
|
затем создается реализация. Тем самым мы можем использовать данные тесты для проверки, что достигается заданное поведение. |
||||||
|
|
||||||
|
Процесс разработки фичи следующий: |
||||||
|
|
||||||
|
- Создать новый тест, который описывает функцию, которая будет реализована. |
||||||
|
- Запустить новый тест и убедиться, что он терпит неудачу. Это ожидаемо, т.к. на данный момент еще нет конкретной реализации. |
||||||
|
- Написать простой код, чтобы новый тест отрабатывал без ошибок. |
||||||
|
- Запустить все тесты и убедиться, что они отрабатывают без ошибок |
||||||
|
- Улучшить код и убедиться, что все тесты все еще отрабатывают без ошибок |
||||||
|
|
||||||
|
После того как это завершено процесс повторяется снова для другой фичи или улучшения. Если существующая фича должна быть изменена, то и тесты |
||||||
|
также должны быть изменены. |
||||||
|
|
||||||
|
> **Подсказка** Если вы чувствуете, что вы теряете время выполняя много мелких и простых итераций, попробуйте покрыть это |
||||||
|
> вашим тестовым сценарием перед следующим выполнением тестов. Если вы слишком много отлаживаете, попробуйте сделать обратное. |
||||||
|
|
||||||
|
Написание тестов до реализации конкретного функционала позволяет нам нам сосредоточиться на том, что мы хотим достичь и полностью |
||||||
|
погрузиться в "как это сделать" впоследствии. |
||||||
|
|
||||||
|
Обычно это приводит к лучшим абстракциям и более легкой поддержке тестов, когда речь идет о корректировки фичи или уменьшении связанности компонентов. |
||||||
|
|
||||||
|
Таким образом плюсы этого подхода следующие: |
||||||
|
|
||||||
|
- Позволяет вам сосредоточиться на одной вещи, что в свою очередь приводит к улучшению планирования и реализации. |
||||||
|
- Более подробное покрытие тестами функционала, таким образом, если все тесты отрабатывают без ошибок, скорее всего, ничего не сломано. |
||||||
|
|
||||||
|
В долгосрочной перспективе это, как правило, дает вам хороший эффект экономии времени. |
||||||
|
|
||||||
|
> **Подсказка**: Если вы хотите узнать больше о принципах сбора требования программного обеспечения и моделирования |
||||||
|
> предметной области, рекомендуем изучить [Проблемно-ориентированное проектирование (DDD)](https://en.wikipedia.org/wiki/Domain-driven_design). |
||||||
|
|
||||||
|
Когда и как тестировать |
||||||
|
----------------------- |
||||||
|
|
||||||
|
Принцип разработки описанный выше имеет смысл применять для долгосрочных и относительно сложных проектов, в то время как для простых это может быть |
||||||
|
излишним. Есть несколько показателей того, когда данный подход уместен: |
||||||
|
|
||||||
|
- Проект уже большой и сложный. |
||||||
|
- Требования к проекту начинают усложняться. Проект постоянно растет. |
||||||
|
- Долгосрочный проект. |
||||||
|
- Цена ошибки очень высока |
||||||
|
|
||||||
|
Нет ничего плохого в создании тестов, покрывающих поведение существующей реализации. |
||||||
|
|
||||||
|
- Legacy-проект который постоянно обновляется. |
||||||
|
- Вам поручили работу над проектом, в котором нет ни одного теста. |
||||||
|
|
||||||
|
В некоторых случаях автоматизированно тестирование может быть излишним: |
||||||
|
|
||||||
|
- Проект простой и не станет более сложным. |
||||||
|
- Это одноразовый проект, который больше не будет дорабатываться. |
||||||
|
|
||||||
|
Тем не менее, если у вас есть время, было бы хорошо автоматизировать тестирование и в этих случаях. |
||||||
|
|
||||||
|
Что почитать |
||||||
|
------------ |
||||||
|
|
||||||
|
- Экстремальное программирование. Разработка через тестирование / Кент Бек. ISBN: 0321146530. |
Loading…
Reference in new issue