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