Merge pull request iliakan#355 from mar-mar/patch-1

iliakan · web-flow · commit e7f4f42c5e07 · 2016-06-25T22:53:43.000+03:00
Откорректирована пунктуация.
diff --git a/1-js/3-writing-js/4-testing/article.md b/1-js/3-writing-js/4-testing/article.md
@@ -6,17 +6,17 @@
 
 ## Зачем нужны тесты?
 
-При написании функции мы обычно представляем, что она должна делать, какое значение -- на каких аргументах выдавать.
+При написании функции мы обычно представляем, что она должна делать, какое значение на каких аргументах выдавать.
 
-В процессе разработки мы, время от времени, проверяем, правильно ли работает функция. Самый простой способ проверить -- это запустить её, например, в консоли, и посмотреть результат.
+В процессе разработки мы время от времени проверяем, правильно ли работает функция. Самый простой способ проверить -- это запустить её, например в консоли, и посмотреть результат.
 
-Если что-то не так -- поправить, опять запустить -- посмотреть результат... И так -- "до победного конца".
+Если что-то не так, поправить, опять запустить -- посмотреть результат... И так "до победного конца".
 
 Но такие ручные запуски -- очень несовершенное средство проверки.
 
 **Когда проверяешь работу кода вручную -- легко его "недотестировать".**
 
-Например, пишем функцию `f`. Написали, тестируем с разными аргументами. Вызов функции `f(a)` -- работает, а вот `f(b)` -- не работает. Поправили код -- стало работать `f(b)`, вроде закончили. Но при этом забыли заново протестировать `f(a)` -- упс, вот и возможная ошибка в коде.
+Например, пишем функцию `f`. Написали, тестируем с разными аргументами. Вызов функции `f(a)` работает, а вот `f(b)` не работает. Поправили код -- стало работать `f(b)`, вроде закончили. Но при этом забыли заново протестировать `f(a)` -- упс, вот и возможная ошибка в коде.
 
 **Автоматизированное тестирование -- это когда тесты написаны отдельно от кода, и можно в любой момент запустить их и проверить все важные случаи использования.**
 
@@ -26,15 +26,15 @@
 
 BDD -- это не просто тесты. Это гораздо больше.
 
-**Тесты BDD -- это три в одном: И тесты И документация И примеры использования одновременно.**
+**Тесты BDD -- это три в одном: И тесты, И документация, И примеры использования.**
 
 Впрочем, хватит слов. Рассмотрим примеры.
 
 ## Разработка pow: спецификация
 
 Допустим, мы хотим разработать функцию `pow(x, n)`, которая возводит `x` в целую степень `n`, для простоты `n≥0`.
 
-Ещё до разработки мы можем представить себе, что эта функция будет делать и описать это по методике BDD.
+Ещё до разработки мы можем представить себе, что эта функция будет делать, и описать это по методике BDD.
 
 Это описание называется *спецификация* (или, как говорят в обиходе, "спека") и выглядит так:
 
@@ -69,11 +69,11 @@ describe("pow", function() {
 
 1. Пишется спецификация, которая описывает самый базовый функционал.
 2. Делается начальная реализация.
-3. Для проверки соответствия спецификации мы задействуем одновременно фреймворк, в нашем случае [Mocha](http://mochajs.org/) вместе со спецификацией и реализацией. Фреймворк запускает все тесты `it` и выводит ошибки, если они возникнут. При ошибках вносятся исправления.
+3. Для проверки соответствия спецификации мы задействуем фреймворк (в нашем случае [Mocha](http://mochajs.org/)). Фреймворк запускает все тесты `it` и выводит ошибки, если они возникнут. При ошибках вносятся исправления.
 4. Спецификация расширяется, в неё добавляются возможности, которые пока, возможно, не поддерживаются реализацией.
-5. Идём на пункт 2, делаем реализацию, и так далее, до победного конца.
+5. Идём на пункт 2, делаем реализацию. И так "до победного конца".
 
-Разработка ведётся *итеративно*, один проход за другим, пока спецификация и реализация не будут завершены.
+Разработка ведётся *итеративно*: один проход за другим, пока спецификация и реализация не будут завершены.
 
 В нашем случае первый шаг уже завершён, начальная спецификация готова, хорошо бы приступить к реализации. Но перед этим проведём "нулевой" запуск спецификации, просто чтобы увидеть, что уже в таком виде, даже без реализации -- тесты работают.
 
@@ -126,11 +126,11 @@ function pow() {
 
 Функция, конечно, ещё не готова, но тесты проходят. Это ненадолго :)
 
-Здесь мы видим ситуацию, которая (и не обязательно при ленивом программисте!)  бывает на практике -- да, есть тесты, они проходят, но увы, функция работает неправильно.
+Здесь мы видим ситуацию, которая (и не обязательно при ленивом программисте!) бывает на практике -- да, есть тесты, они проходят, но функция (увы!) работает неправильно.
 
 **С точки зрения BDD, ошибка при проходящих тестах --  вина спецификации.**
 
-В первую очередь не реализация исправляется, а уточняется спецификация, пишется (падающий) тест.
+В первую очередь не реализация исправляется, а уточняется спецификация, пишется падающий тест.
 
 Сейчас мы расширим спецификацию, добавив проверку на `pow(3, 4) = 81`.
 
@@ -166,7 +166,7 @@ function pow() {
     });
     ```
 
-Их принципиальное различие в том, что если `assert` обнаруживает ошибку, то он тут же прекращает выполнение блоки `it`. Поэтому в первом варианте, если вдруг первый `assert` "провалился", то про результат второго мы никогда не узнаем.
+Их принципиальное различие в том, что если `assert` обнаруживает ошибку, то он тут же прекращает выполнение блока `it`. Поэтому в первом варианте, если вдруг первый `assert` "провалился", то про результат второго мы никогда не узнаем.
 
 **Таким образом, разделить эти тесты может быть полезно, чтобы мы получили больше информации о происходящем.**
 
@@ -345,7 +345,7 @@ describe("pow", function() {
 
 Однако, между этими вызовами есть отличие в деталях сообщения об ошибке.
 
-При "упавшем" `assert` в примере выше мы видим `"Unspecified AssertionError"`, то есть просто "что-то пошло не так", а при `assert.equal(value1, value2)` -- будут дополнительные подробности: `expected 8 to equal 81`.
+При "упавшем" `assert` в примере выше мы видим `"Unspecified AssertionError"`, то есть просто "что-то пошло не так", а при `assert.equal(value1, value2)` будут дополнительные подробности: `expected 8 to equal 81`.
 
 **Поэтому рекомендуется использовать именно ту проверку, которая максимально соответствует задаче.**
 
@@ -417,7 +417,7 @@ describe("pow", function() {
 
 **Код, покрытый автотестами, являет собой полную противоположность этому!**
 
-Даже если какое-то изменение потенциально может порушить всё -- его совершенно не страшно сделать. Ведь есть масса тестов, которые быстро и в автоматическом режиме проверят работу кода и, если что-то падает -- это можно будет легко локализовать и поправить.
+Даже если какое-то изменение потенциально может порушить всё -- его совершенно не страшно сделать. Ведь есть масса тестов, которые быстро и в автоматическом режиме проверят работу кода. И если что-то падает, то это можно будет легко локализовать и поправить.
 
 **Кроме того, код, покрытый тестами, имеет лучшую архитектуру.**
 
