# Тестирование - обязательный этап разработки

(В оригинале - Testing Is the Engineering Rigor of Software Development)

Программисты любят использовать метафоры, объясняя, что они делают, членам семьи и другим нетехническим людям. Часто при этом происходит сравнение со строительством моста и другими «реальными» примерами проектирования. Однако эти метафоры перестают работать, если попытаться зайти в их использовании слишком далеко. Все же разработка ПО сильно отличается от строительства материальных объектов.

Если применить аналогии разработки ПО к строительству моста, то строители моста должны после его постройки провезти по нему что-нибудь тяжелое. Если мост выстоит – значит, он построен правильно. Если же нет – значит, надо искать и исправлять проблемы в чертеже и начинать все заново. Все последнее тысячелетие инженеры разрабатывали математический аппарат, позволяющий им просчитать конструкцию материального предмета до его реальной постройки и без его реальной постройки. В разработке ПО такого аппарата пока нет и, похоже, не предвидится именно потому, что разработка ПО сильно отличается от реального строительства. Очень детальное сравнение сделал Джек Ривз (Jack Reeves) в статье «Что такое дизайн ПО» (["What is Software Design?"](http://www.developerdotstar.com/mag/articles/reeves_design.html)) в журнале «С++» (C++ Journal) в 1992 году. Несмотря на то, что написано это было почти двадцать лет назад, изложенный там материал все еще актуален. Он нарисовал достаточно мрачную картину, но тогда, в 1992-м году еще не была достаточно развита традиция интенсивного тестирования ПО.

Тестирование в материальном мире – трудная задача, ведь вам необходимо физически построить то, что вы собираетесь тестировать. Построить что-то лишь для того, чтобы посмотреть, что получится в результате – звучит как-то не очень оптимистично. Однако «стройка» в программировании обходится значительно дешевле. И специально для тестирования разработаны целые системы инструментов – юнит-тестирование, мок-объекты (mock-objects), платформы для тестирования и другие подобные вещи. Инженеры материального мира могут только мечтать о том, чтобы что-нибудь построить для тестирования в реальных условиях. Как разработчики ПО, мы должны принять тестирование как основное (но не единственное) средство проверки работоспособности ПО. Вместо ожидания появления какого-нибудь механизма, позволяющего просчитать поведение ПО (по аналогии с материальным миром), мы должны использовать то, что у нас уже есть. Посмотрев на процесс с этой точки зрения, мы теперь можем адекватно возражать менеджеру, говорящему «У нас нет времени на тестирование». Ведь строитель моста никогда не услышит от своего босса «Никакого структурного анализа – нас поджимает дедлайн!». Понимание того, что тестирование – это путь к качественному ПО, позволяет нам, разработчикам, отбрасывать аргументы против тестирования как непрофессиональные.

Да, тестирование требует времени. Также как и структурный анализ материального объекта требует времени. Оба процесса обеспечивают качество конечного продукта. Пришло время программистам взять ответственность за производимый ими продукт. Одного тестирования для этого недостаточно, но оно необходимо. Тестирование – это обязательная часть процесса разработки.

Автор оригинала - [Neal Ford](http://programmer.97things.oreilly.com/wiki/index.php/Neal_Ford)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/ru/thing_80.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.