Малий процес розробки: Git, модульні тести та review

Мета і підготовка

Пройти від вимоги до логічного commit та перевіреного результату для невеликої консольної програми. Потрібно знати функції Python, контракти й основи тестування. Встановіть Python і Git, перевірте python --version та git --version. Створіть окрему локальну папку quality-lab; публікація у зовнішній сервіс для цієї роботи не потрібна.

Теоретичний мінімум

Commit фіксує зміни, додані до індексу Git. Diff показує різницю між станами. Модульний тест виконує поведінку на визначених даних та порівнює результат із контрактом. Review перевіряє причину зміни, її межі й достатність доказів. Умови готовності погоджують до початку роботи, щоб завершення не залежало лише від особистого відчуття автора.

Наша демонстрація обчислює оплату за копії навчального документа. Кількість сторінок — невід’ємне ціле число, ціна однієї сторінки — невід’ємне ціле число копійок. Цілі копійки дозволяють уникнути похибок двійкового представлення дробів у простому розрахунку. Функція обчислення не читає консоль і не записує файл; ці дії належать зовнішньому інтерфейсу.

Повний демонстраційний код

Збережіть у pricing.py:

def total_kopecks(pages: int, unit_price: int) -> int:
    if pages < 0 or unit_price < 0:
        raise ValueError("Значення мають бути невід’ємними")
    # Кількість і ціна передаються в узгоджених одиницях.
    return pages * unit_price

Збережіть у test_pricing.py:

import unittest
from pricing import total_kopecks

class PricingTests(unittest.TestCase):
    def test_three_pages(self):
        self.assertEqual(total_kopecks(3, 150), 450)

    def test_zero_pages(self):
        self.assertEqual(total_kopecks(0, 150), 0)

    def test_negative_input(self):
        with self.assertRaises(ValueError):
            total_kopecks(-1, 150)

if __name__ == "__main__":
    unittest.main()

Запустіть python -m unittest -v. Очікуються три успішні тести. from pricing import імпортує функцію з сусіднього файлу; -v показує назви перевірок. Кожен тест називає поведінку та використовує конкретні дані. Позитивний приклад перевіряє арифметику, нуль — границю, від’ємний вхід — контракт помилки.

Покрокове виконання процесу

Спершу створіть README з вимогою, одиницями й командою запуску. Додайте .gitignore для __pycache__/ та локального віртуального середовища. Ініціалізуйте Git, перегляньте статус і додайте лише потрібні файли. Перед commit перегляньте staged diff. Повідомлення має описувати завершену поведінку, наприклад «додати розрахунок оплати й граничні перевірки».

git init
git status --short
git add pricing.py test_pricing.py README.md .gitignore
git diff --cached
git commit -m "Add document pricing with boundary tests"

Якщо Git потребує імені й email, налаштуйте їх локально для навчального репозиторію за власними даними. Не вставляйте токени, паролі або приватні файли. Після commit статус потрібних файлів має бути чистим. Зміна лише часу модифікації файлу не є новою зміною вмісту Git.

Далі додайте вимогу знижки для певної кількості сторінок. Спочатку запишіть приклади на границі й створіть тест, який має виявити відсутню поведінку. Запустіть його, зафіксуйте очікувану відмову, реалізуйте зміну й повторіть перевірки. Визначте правило округлення до копійки до написання коду. Зафіксуйте результат окремим логічним commit.

Самостійне завдання

Створіть модуль розрахунку вартості для обраного сценарію: друк, доставка або погодинне користування обладнанням. Задайте базову ціну, одне додаткове правило та контракт некоректного входу. Напишіть щонайменше п’ять поведінкових тестів. Власне правило й реалізацію потрібно розробити самостійно; демонстрація показує лише структуру модуля та перевірок.

Проведіть review за питаннями: чи збігаються одиниці, чи визначене округлення, чи тести перевіряють границю, чи логіка залежить від зовнішнього стану, чи зрозуміла причина зміни. Для роботи без партнера зробіть письмовий self-review після перерви й запишіть підтверджені зауваження. Коментар має вказувати конкретний приклад, що виявляє ризик.

Типові помилки та налагодження

Команда unittest шукає файли за шаблоном test*.py; неправильна назва може дати нуль тестів. Імпорт залежить від робочої папки. Тест із правильним арифметичним прикладом не перевіряє округлення. Додавання всіх файлів без перегляду може включити кеш чи секрет. Відтворюйте збій окремою командою та перевіряйте кількість реально виконаних тестів.

Очікуваний результат і контрольні питання

Подайте README, модуль, тести, короткий журнал review і два-три логічні commits. Поясніть, чому ціна задана копійками, які ризики покриті тестами й як відтворити роботу після копіювання папки. Чим staged diff відрізняється від звичайного diff? Яка перевірка виявить зміну правила на границі? Що зелений запуск тестів ще не гарантує?

Дослідження помилки та історія зміни

Після першого проходження тестів навмисно змініть одну арифметичну операцію демонстрації, наприклад додавання на віднімання. Запустіть перевірку та визначте, який сценарій виявив дефект. Поверніть правильну операцію й переконайтеся, що результат знову успішний. Такий контрольований дослід показує, чи тест справді чутливий до потрібної поведінки.

Для індивідуальної знижки погодьте правило округлення до копійки. Добуток цілих копійок і відсотка може мати дробову частину; різні способи округлення дають різний результат біля межі. Збережіть два конкретні приклади, які відрізняють ваш контракт від інших можливих правил. Не обирайте очікування після перегляду фактичного виводу.

Перед комітом прочитайте різницю файлів. Перевірте, чи у змінах є лише реалізація, тести й потрібна документація, чи випадково додано середовище або результати запуску. Повідомлення коміту має описувати завершену поведінку, наприклад правило обчислення знижки та його перевірку. За історією має бути зрозуміло, чому правило змінилося.

У звіті наведіть одну невдалу перевірку, причину, виправлення та повторний результат. Це відтворюваний доказ налагодження. Окремо вкажіть версію Python та команду запуску, щоб інший студент міг перевірити вашу роботу з чистої копії. Не додавайте приватні дані або облікові ключі для демонстрації командної розробки.

Схема процесу

Самоперевірка

Підсумок

Невеликий процес розробки поєднує контракт, тести, реалізацію та review. Git фіксує перевірений стан, а README забезпечує відтворення. Перегляд staged diff і поведінкових границь допомагає уникати випадкових змін.

Джерела

• Python tutorial
• unittest
• Git book