Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!20.02.2023
Навіщо писати тести потім?
Сьогодні практично весь день писав тести для коду, який вже був написаний. Насправді навіть не для коду, а для розрізів в базі. Але тести на RSpec, бо кращого способу не знаю.
Взагалі я не прихильник TDD, та скоріше навіть відхильник, принаймні писати тести спочатку мені ніколи не подобалось. Завжди це здавалось якимсь ритуально-театральним підходом. В мене код зазвичай починається з “вертикальної скибочки”, коли все від початка до кінця працює, але в обмеженій кількості. Коли щось таке працює, починаю розбивати на акуратні модулі, тестувати, доповнювати деталями.
Тести для мене — це спосіб викликати код з різними аргументами, деколи такими, що вручну створити складно. Тобто технічно це завжди спрощення ручної роботи. Тож, як на мене, коли тести перетворюються в складну роботу — треба шукати, що з ними не так. Або тестувати на іншому рівні — юніт-тести не завжди найкраще рішення, інколи можна більше зрозуміти по інтеграційнім. Або замислитись, якого контексту не вистачає — інколи гарно написані фабрики або допоміжний код з жахливих тестів роблять такі, що і писати, і читати приємно.
А ще нещодавно придумав брати скриншоти з інтеграційних тестів як ілюстрацію до PRів. (Для цього в Capybara є функція save_screenshot
.) Так можна підготувати ілюстрації до різних контекстів та без проблем оновити їх, якщо в коді будуть зміни.