feat(1-02-01-hello-world): Fix language mistakes in 05-testing-mocha

Author: ltlaitoff

1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md

@@ -1,4 +1,4 @@
-Тест демонструє одну із спокус, з якою стикається розробник, коли пише тести.
+Тест демонструє одну зі спокус, з якою стикається розробник, коли пише тести.
 
 Що ми маємо тут, це насправді 3 тести, але вони були описані однією функцією з 3 припущеннями.
 

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

@@ -18,11 +18,11 @@
 
 Це дуже типово. Коли ми щось розробляємо, ми пам’ятаємо про багато можливих випадків використання. Але не треба очікувати, що програміст перевірятиме їх усі вручну після кожної зміни. Так стає легко виправити щось одне і зламати інше.
 
-**Автоматизоване тестування означає, що тести пишуться окремо від основного коду, доповнюючи його. Вони запускають наші функції різними способами і порівнюють результати з очікуваними.**
+**Автоматизоване тестування означає, що тести пишуться окремо від основного коду, доповнюючи його. Вони запускають наші функції різними способами та порівнюють результати з очікуваними.**
 
 ## Керована поведінкою розробка (BDD)
 
-Давайте розпочнемо з техніки під назвою [Керована поведінкою розробка](https://uk.wikipedia.org/wiki/Керована_поведінкою_розробка) або коротко, BDD (від англ. behavior-driven development).
+Розпочнімо з техніки під назвою [Керована поведінкою розробка](https://uk.wikipedia.org/wiki/Керована_поведінкою_розробка) або коротко, BDD (від англ. behavior-driven development).
 
 **BDD це три в одному: і тести, і документація, і приклади використання.**
 
@@ -32,7 +32,7 @@
 
 Припустимо, ми хочемо зробити функцію `pow(x, n)`, яка піднесе `x` до степеня `n`. Ми припускаємо, що `n≥0`.
 
-Це завдання є просто прикладом - в JavaScript є оператор `**`, що підносить до степеня, але в цьому прикладі ми зосередимось на процесі розробки, який потім можна також застосовувати і для більш складних завдань.
+Це завдання є просто прикладом - в JavaScript є оператор `**`, що підносить до степеня, але в цьому прикладі ми зосередимось на процесі розробки, який потім можна також застосовувати й для складніших завдань.
 
 Перш ніж створити код для функції `pow ', ми можемо уявити, що вона повинна виконувати, і описати її.
 
@@ -57,11 +57,11 @@ describe("pow", function() {
 : У першому аргументі (назві) `it` ми описуємо *людською мовою* конкретний спосіб використання функції, а у другому аргументі пишемо функцію, яка тестуватиме цей спосіб.
 
 `assert.equal(value1, value2)`
-: Код, всереді блоку `it`, якщо реалізація правильна, повинен виконуватись без помилок.
+: Код, всередині блоку `it`, якщо реалізація правильна, повинен виконуватись без помилок.
 
     Функції `assert.*` використовуються для перевірки того, що функція `pow` працює, як ми очікуємо. В нашому випадку, ми використовуємо одну з них -- `assert.equal`, вона порівнює аргументи і сповіщає про помилку, якщо вони відрізняються. Тут вона перевіряє, що результат `pow(2, 3)` дорівнює `8`. Є також інші способи порівняння та перевірки, які ми розглянемо пізніше.
 
-Специфікацію можна виконати, і вона у свою чергу виконає тести вказані у блоках `it`. Ми розглянемо це далі.
+Специфікацію можна виконати, і вона автоматично виконає тести вказані у блоках `it`. Ми розглянемо це далі.
 
 ## Процес розробки
 
@@ -71,15 +71,15 @@ describe("pow", function() {
 2. Створюється початкова реалізація.
 3. Щоб перевірити, чи вона працює, ми використовуємо тестовий фреймворк [Mocha](https://mochajs.org/) (більш детально нижче), який виконує специфікацію. Якщо функціонал не завершено -- виводяться повідомлення про помилки. Ми робимо виправлення до тих пір, поки не матимемо повністю робочий код.
 4. Тепер ми маємо початкову реалізацію з тестами.
-5. Ми додаємо більше способів використання до специфікації, навіть таких, що поки що не підтримуються реалізацією. Виконання тестів знову завершиться невдачою.
+5. Ми додаємо більше способів використання до специфікації, навіть таких, що поки що не підтримуються реалізацією. Виконання тестів знову завершиться невдачею.
 6. Переходимо на 3-й пункт, змінюємо реалізацію, щоб вона відповідала тестам і вони не повертали повідомлення про помилку.
 7. Повторюємо процес, описаний у пунктах з 3-го по 6-ий, поки функціонал не буде повністю готовий.
 
 Тобто, процес розробки є *ітеративним*. Ми пишемо специфікацію, реалізуємо її, переконуємось, що тести проходять, потім пишемо ще тести, переконуємось, що вони також проходять і т.д. Завершивши цей процес, ми маємо реалізований робочий функціонал і тести до нього.
 
-Давайте розглянемо цей процес розробки на нашому прикладі.
+Розгляньмо цей процес розробки на нашому прикладі.
 
-Перший пункт вже виконано -- ми маємо первинну специфікацію для функції `pow`. Тепер, перед початком написання коду, давайте використаємо декілька бібліотек JavaScript для запуску тестів, щоб перевірити, що вони працюють (звичайно, без коду функції, вони всі завершаться невдачою).
+Перший пункт вже виконано -- ми маємо первинну специфікацію для функції `pow`. Тепер, перед початком написання коду, використаймо декілька бібліотек JavaScript для запуску тестів, щоб перевірити, що вони працюють (звичайно, без коду функції, вони всі завершаться невдачею).
 
 ## Специфікація в дії
 
@@ -108,13 +108,13 @@ describe("pow", function() {
 
 [iframe height=250 src="pow-1" border=1 edit]
 
-Поки що тест провалюється, є помилка. Це логічно - код функції `pow` пустий, тобто `pow(2,3)` поверає `undefined` замість `8`.
+Поки що тест провалюється, є помилка. Це логічно - код функції `pow` пустий, тобто `pow(2,3)` повертає `undefined` замість `8`.
 
 На майбутнє зазначимо, що є більш високорівневі засоби для запуску тестів, наприклад [karma](https://karma-runner.github.io/) та інші, які полегшують автоматичний запуск різних тестів.
 
 ## Первинна реалізація
 
-Давайте розробимо первинну реалізацію функції `pow`, щоб тести проходили:
+Розробімо первинну реалізацію функції `pow`, щоб тести проходили:
 
 ```js
 function pow(x, n) {
@@ -166,7 +166,7 @@ function pow(x, n) {
     });
     ```
 
-Принципова відмінність полягає в тому, що коли `assert` повертає помилку, блок `it` негайно припиняється. Отже, у першому варіанті, якщо перший `assert` не вдасться, ми ніколи не отримаємо результат другого` assert`.
+Принципова відмінність полягає в тому, що коли `assert` повертає помилку, блок `it` негайно припиняється. Отже, у першому варіанті, якщо перший `assert` не вдасться, ми ніколи не отримаємо результат другого `assert`.
 
 Створення тестів окремо корисно, щоб отримати більше інформації про те, що відбувається, так що другий варіант краще.
 
@@ -186,7 +186,7 @@ function pow(x, n) {
 
 ## Вдосконалення реалізації
 
-Давайте напишемо щось більш реальне для проходження тестів:
+Напишімо щось більш реальне для проходження тестів:
 
 ```js
 function pow(x, n) {
@@ -200,7 +200,7 @@ function pow(x, n) {
 }
 ```
 
-Щоб переконатися, що функція працює правильно, давайте перевіримо більше значень. Замість того, щоб писати блоки `it` вручну, ми можемо генерувати їх в циклі `for`:
+Щоб переконатися, що функція працює правильно, перевірмо більше значень. Замість того, щоб писати блоки `it` вручну, ми можемо генерувати їх в циклі `for`:
 
 ```js
 describe("pow", function() {
@@ -225,7 +225,7 @@ describe("pow", function() {
 
 ## Вкладені інструкції "describe"
 
-Ми додамо ще більше тестів. Але перед цим зазначимо, що дпоміжна функція `makeTest` та цикл `for` повинні бути згруповані разом. Нам не знадобиться `makeTest` в інших тестах - вона потрібна лише для циклу `for` - їх спільне завдання перевіряти `pow`, звівши число до заданого степеня.
+Ми додамо ще більше тестів. Але перед цим зазначимо, що допоміжна функція `makeTest` та цикл `for` повинні бути згруповані разом. Нам не знадобиться `makeTest` в інших тестах - вона потрібна лише для циклу `for` - їх спільне завдання перевіряти `pow`, звівши число до заданого степеня.
 
 Групування проводиться за допомогою вкладеної інструкції `describe`:
 
@@ -296,12 +296,12 @@ describe("test", function() {
 
 [edit src="beforeafter" title="Відкрити приклад в пісочниці."]
 
-Як правило, `beforeEach/afterEach` і `before/after` використовуються для виконання ініціалізації, обнулення лічильників або ще для чогось між тестами (або групами тестів).
+Як правило, `beforeEach/afterEach` і `before/after` використовуються для виконання ініціалізації, скидання лічильників або ще для чогось між тестами (або групами тестів).
 ````
 
 ## Розширення специфікації
 
-Основна функціональність `pow` завершена. Перша ітерація розробки завершена. Відсвяткувавши та випивши шампанське, давайте продовжемо вдосконалювати її.
+Основна функціональність `pow` завершена. Перша ітерація розробки завершена. Відсвяткувавши та випивши шампанське, продовжмо вдосконалювати її.
 
 Як було сказано, функція `pow(x, n)` має працювати з додатними цілими значеннями `n`.
 
@@ -387,23 +387,23 @@ function pow(x, n) {
 
 Це особливо важливо для великих проєктів, коли функція використовується в багатьох місцях. Коли ми змінюємо таку функцію, просто неможливо вручну перевірити, чи кожне місце, яке її використовує, все ще працює правильно.
 
-Без тестів люди мають два варіанта:
+Без тестів люди мають два варіанти:
 
 1. Здійснити зміну, незважаючи ні на що. І тоді наші користувачі зустрічаються з помилками, оскільки ми, мабуть, не перевірили щось вручну.
 2. Або, якщо покарання за помилки суворе, оскільки немає тестів, люди бояться змінювати такі функції, і тоді код застаріває, ніхто не хоче його правити. Це не добре для розробки.
 
 **Автоматичне тестування допомагає уникнути цих проблем!**
 
-Якщо проєкт покритий тестами, такої проблеми просто немає. Після будь-яких змін ми можемо запустити тести і побачити безліч перевірок, зроблених за лічені секунди.
+Якщо проєкт покритий тестами, такої проблеми просто немає. Після будь-яких змін ми можемо запустити тести й побачити безліч перевірок, зроблених за лічені секунди.
 
 **Крім того, добре перевірений код має кращу архітектуру.**
 
 Звісно, це тому, що автоматично перевірений код легше змінювати та вдосконалювати. Але є й інша причина.
 
 Для написання тестів код повинен бути організований таким чином, щоб кожна функція мала чітко описане завдання, чітко визначені вхідні дані та вихідний результат. Це означає хорошу архітектуру з самого початку.
 
-У реальному житті це часом не так просто. Іноді складно написати специфікацію перед фактичним кодом, тому що ще не зрозуміло, як вона повинна вести себе. Але в цілому написання тестів робить розробку швидшою і стабільнішою.
+У реальному житті це часом не так просто. Іноді складно написати специфікацію перед фактичним кодом, тому що ще не зрозуміло, як він повинен поводитись. Але в цілому написання тестів робить розробку швидшою і стабільнішою.
 
 Пізніше в підручнику ви зустрінете багато завдань з тестами. Тож ви побачите більше практичних прикладів.
 
-Написання тестів вимагає хороших знань JavaScript. Але ми тільки починаємо це вивчати. Отже, не хвилюйтесь, поки що вам не потрібно писати тести, але ви вже маєте можливість їх прочитати, навіть якщо вони будут трохи складніші, ніж ті, що навдені у цій главі.
+Написання тестів вимагає хороших знань JavaScript. Але ми тільки починаємо це вивчати. Отже, не хвилюйтесь, поки що вам не потрібно писати тести, але ви вже маєте можливість їх прочитати, навіть якщо вони будуть трохи складніші, ніж ті, що наведені у цій главі.