Merge pull request #8686 from unclead/guide-ru-test-overview

Translation of guide-ru/test-overview.dm part [skip ci]

docs/guide-ru/README.md

@@ -148,10 +148,11 @@ All Rights Reserved.
 Тестирование
 ------------
 
-* **TBD** [Обзор](test-overview.md)
-* **TBD** [Модульные тесты](test-unit.md)
-* **TBD** [Функциональные тесты](test-functional.md)
-* **TBD** [Приёмочные тесты](test-acceptance.md)
+* [Обзор](test-overview.md)
+* [Настройка тестового окружения](test-environment-setup.md)
+* [Модульные тесты](test-unit.md)
+* [Функциональные тесты](test-functional.md)
+* [Приёмочные тесты](test-acceptance.md)
 * [Фикстуры](test-fixtures.md)
 
 

docs/guide-ru/test-overview.md

@@ -0,0 +1,76 @@
+Тестирование
+============
+
+Тестирование является важной составляющей разработки программного обеспечения. Мы проводим тестирование непрерывно, осознаем мы это или нет.
+Например, когда мы пишем класс на языке PHP, мы может отлаживать его шаг за шагом или просто использовать `echo` или `die` для проверки, что
+реализация работает в соответствии с намеченным планом. В случае веб приложения, мы вводим некоторые тестовые данные в форму для того, чтобы
+убедиться, что страница взаимодействует с нами, как ожидается.
+
+Процесс тестирования может быть автоматизирован так, что каждый раз когда нам нужно что-то проверить, мы просто должны 
+вызвать код, который сделает это за нас. Код, который проверяет, что результат совпадает с тем, что мы планировали, называется тестом, а процесс
+создания тестов и их последующего использования - автоматизированным тестированием, что и является главной темой данного раздела.
+
+
+Разработка с тестами
+--------------------
+
+Разработка через тестирование (TDD) и разработка через поведение (BDD) - это подходы разработки программного обеспечения, в рамках которых
+поведение части кода или целая фича описывается в виде набора сценариев или тестов ДО написания фактического кода и только
+затем создается реализация. Тем самым мы можем использовать данные тесты для проверки, что достигается заданное поведение.
+
+Процесс разработки фичи следующий:
+
+- Создать новый тест, который описывает функцию, которая будет реализована.
+- Запустить новый тест и убедиться, что он терпит неудачу. Это ожидаемо, т.к. на данный момент еще нет конкретной реализации.
+- Написать простой код, чтобы новый тест отрабатывал без ошибок.
+- Запустить все тесты и убедиться, что они отрабатывают без ошибок
+- Улучшить код и убедиться, что все тесты все еще отрабатывают без ошибок
+
+После того как это завершено процесс повторяется снова для другой фичи или улучшения. Если существующая фича должна быть изменена, то и тесты
+также должны быть изменены.
+
+> **Подсказка** Если вы чувствуете, что вы теряете время выполняя много мелких и простых итераций, попробуйте покрыть это 
+> вашим тестовым сценарием перед следующим выполнением тестов. Если вы слишком много отлаживаете, попробуйте сделать обратное.
+
+Написание тестов до реализации конкретного функционала позволяет нам нам сосредоточиться на том, что мы хотим достичь и полностью
+погрузиться в "как это сделать" впоследствии. 
+
+Обычно это приводит к лучшим абстракциям и более легкой поддержке тестов, когда речь идет о корректировки фичи или уменьшении связанности компонентов.
+
+Таким образом плюсы этого подхода следующие:
+
+- Позволяет вам сосредоточиться на одной вещи, что в свою очередь приводит к улучшению планирования и реализации.
+- Более подробное покрытие тестами функционала, таким образом, если все тесты отрабатывают без ошибок, скорее всего, ничего не сломано.
+
+В долгосрочной перспективе это, как правило, дает вам хороший эффект экономии времени.
+
+> **Подсказка**: Если вы хотите узнать больше о принципах сбора требования программного обеспечения и моделирования
+> предметной области, рекомендуем изучить [Проблемно-ориентированное проектирование (DDD)](https://en.wikipedia.org/wiki/Domain-driven_design).
+
+Когда и как тестировать
+-----------------------
+
+Принцип разработки описанный выше имеет смысл применять для долгосрочных и относительно сложных проектов, в то время как для простых это может быть
+излишним. Есть несколько показателей того, когда данный подход уместен:
+
+- Проект уже большой и сложный.
+- Требования к проекту начинают усложняться. Проект постоянно растет.
+- Долгосрочный проект.
+- Цена ошибки очень высока
+
+Нет ничего плохого в создании тестов, покрывающих поведение существующей реализации.
+
+- Legacy-проект который постоянно обновляется.
+- Вам поручили работу над проектом, в котором нет ни одного теста.
+
+В некоторых случаях автоматизированно тестирование может быть излишним:
+
+- Проект простой и не станет более сложным.
+- Это одноразовый проект, который больше не будет дорабатываться.
+
+Тем не менее, если у вас есть время, было бы хорошо автоматизировать тестирование и в этих случаях.
+
+Что почитать
+------------
+
+- Экстремальное программирование. Разработка через тестирование / Кент Бек. ISBN: 0321146530.