правки lex111

Author: xcurveballx

1-js/03-code-quality/05-testing-mocha/article.md

@@ -6,9 +6,9 @@
 
 ## Зачем нам нужны тесты?
 
-Обычно, когда мы пишим функцию, мы легко можем представить что она должна делать и как она будет вести себя в зависимосте от переданных аргуметнов. 
+Обычно, когда мы пишем функцию, мы легко можем представить, что она должна делать и как она будет вести себя в зависимости от переданных параметров.
 
-Во время разработки мы можем проверить правильность работы функции просто вызвав ее, например из консоли, и сравнив полученый результат с ожидаемым.
+Во время разработки мы можем проверить правильность работы функции просто вызвав ее, например из консоли, и сравнив полученный результат с ожидаемым.
 
 Если функция работает не так, как мы ожидаем, можно исправить код и запустить её еще раз. Так можно повторять до тех пор, пока функция не станет работать так, как нам нужно.
 
@@ -62,7 +62,7 @@ describe("pow", function() {
 : В случае правильной реализации функции для тестируемого случая, код внитри блока `it` должен выполняться без ошибок.
 
     Функции `assert.*` используются для проверки того что функция `pow` работает так, как мы ожидаем. В этом примере мы используем одну их них -- `assert.equal`, которая сравнивает переданные значения и выбрасывает ошибку если они не равны друг другу.
-    
+
     Существуют и другие типы сравнения и проверок. Их мы рассмотрим позднее.
 
 ## Процесс разработки
@@ -116,7 +116,7 @@ For the future, let's note that there are advanced test-runners, like [karma](ht
 
 ## Начальная реализация
 
-Давайте напишем простую реализацию функции `pow` что бы пройти тесты. 
+Давайте напишем простую реализацию функции `pow` что бы пройти тесты.
 
 ```js
 function pow(x, n) {
@@ -253,7 +253,7 @@ describe("pow", function() {
   });
 */!*
 
-  // ... другие тесты. Можно писать и describe и it блоки. 
+  // ... другие тесты. Можно писать и describe и it блоки.
 });
 ```
 
@@ -262,7 +262,7 @@ describe("pow", function() {
 [iframe height=250 src="pow-4" edit border="1"]
 
 In the future we can add more `it` and `describe` on the top level with helper functions of their own, they won't see `makeTest`.
-В будущем мы можем написать новые `it` и `describe` блоки на верхнем уровне со своими собственными вспомогательными функциями. Им не будет доступна функция `makeTest` из примера выше. 
+В будущем мы можем написать новые `it` и `describe` блоки на верхнем уровне со своими собственными вспомогательными функциями. Им не будет доступна функция `makeTest` из примера выше.
 
 ````smart header="`before/after` и `beforeEach/afterEach`"
 Мы можем /after` функции которые будут выполняться до/после тестов, а так-же функции `beforeEach/afterEach` выполняемые до/после *каждого* `it`.
@@ -400,15 +400,15 @@ Now it works, all tests pass:
 
 **Автоматическое тестирование кода против этого!**
 
-Если проект покрыт тестами, то выше упомянуты проблемы не возникают. Мы можем запустить тесты и увидить результаты огромного количества проверок, сделанных за секунды. 
+Если проект покрыт тестами, то выше упомянуты проблемы не возникают. Мы можем запустить тесты и увидить результаты огромного количества проверок, сделанных за секунды.
 
 **Кроме того, код, хорошо покрытый тестами, как правило имеет более лучшую архитектуру.**
 
 Естественно, его легче менять и улучшать. Но не только из-за этого.
 
-Для написания тестов нужно организовать код таким образом что бы у каждой функции была ясно поставленная задача и точно определены её аргументы и возвращаемое значение. А это означает что мы получаем хорошую архетектуру с самого начала. 
+Для написания тестов нужно организовать код таким образом что бы у каждой функции была ясно поставленная задача и точно определены её аргументы и возвращаемое значение. А это означает что мы получаем хорошую архетектуру с самого начала.
 
-В реальносте это невсегда так просто. Иногда сложно написать спецификацию до того как будет написана реализация потому что не всегда чётко понятно как та или иная функция должна себя вести. 
+В реальносте это невсегда так просто. Иногда сложно написать спецификацию до того как будет написана реализация потому что не всегда чётко понятно как та или иная функция должна себя вести.
 
 ## Что теперь?