Не дозволите да се тестни код увуче у производњу

ТЛ;ДР: Избегавајте додавање исТестинг или сличних заставица.

Проблеми 😔

• Пропуштена апстракција
• Загађење не-пословног кода
• Фрагиле Цоде
• Недоследно понашање
• Скривене зависности
• Тешко отклањање грешака
• Боолеан флагс
• Непоуздани тестови
• Код зависан од производње

Решења 😃

1. Уклони понашање Ифс
2. Користите ињекцију зависности
3. Моделирајте екстерне услуге (немојте им се ругати )
4. Одвојене конфигурације
5. Изолујте логику теста
6. Одржавајте чисте границе понашања

Рефакторинг ⚙

Контекст 💬

Када додате заставице као што је исТестинг , мешате тестирање и производни код.

Ово ствара скривене путање које су активне само у тестовима.

Такође, не покривате прави производни код.

Ризикујете да испоручите понашање тестирања у производњу, што ће довести до грешака и непредвидивог понашања.

Пример кода 📖

Погрешно ❌

 struct PaymentService { is_testing: bool, } impl PaymentService { fn process_payment(&self, amount: f64) { if self.is_testing { println!("Testing mode: Skipping real payment"); return; } println!("Processing payment of ${}", amount); } }

Тачно 👉

 trait PaymentProcessor { fn process(&self, amount: f64); } struct RealPaymentProcessor; impl PaymentProcessor for RealPaymentProcessor { fn process(&self, amount: f64) { println!("Processing payment of ${}", amount); } } struct TestingPaymentProcessor; impl PaymentProcessor for TestingPaymentProcessor { // Notice this is not a mock fn process(&self, _: f64) { println!("No payment: Skipping real transaction"); } } struct PaymentService<T: PaymentProcessor> { processor: T, } impl<T: PaymentProcessor> PaymentService<T> { fn process_payment(&self, amount: f64) { self.processor.process(amount); } }

Детецтион 🔍

• [к] Полуаутоматски

Овај мирис можете открити тражењем условних заставица као што су исТестинг , окружење == 'тест' , ДЕБУГ_МОДЕ и идиоми попут ових.

Ово указује на то да понашање тестирања цури у производни код.

Ознаке 🏷

• Тестирање

Ниво 🔋

• [к] Средњи

Зашто је бијекција важна 🗺

Потребно вам је јасно раздвајање између тестног и производног кода.

Када их помешате, прекидате везу један на један између понашања у стварном свету и програма.

Пошто су окружења ентитети из стварног света, потребно је да их експлицитно моделујете у МАППЕР-у .

АИ генерација 🤖

Код генерисан од вештачке интелигенције често уводи овај мирис када користите брзе хакове за тестирање.

Неки алати предлажу заставице као што је исТестинг јер дају предност лакоћи у односу на правилан дизајн.

АИ детекција 🥃

АИ алати могу ухватити овај мирис ако их конфигуришете да означавају условну логику на основу стања тестирања.

Пробајте их! 🛠

Запамтите: АИ асистенти праве много грешака

Предложени упит: Уклоните метод ИсТестинг и замените га моделирањем окружења

Закључак 🏁

Избегавајте коришћење исТестинг заставица.

Користите ињекцију зависности и моделирајте окружења да бисте држали логику тестирања и производње одвојене.

Односи 👩‍❤‍💋‍👨

хттпс://хацкерноон.цом/хов-то-финд-тхе-стинки-партс-оф-иоур-цоде-парт-ккии

хттпс://хацкерноон.цом/хов-то-финд-тхе-стинки-партс-оф-иоур-цоде-парт-киии

хттпс://хацкерноон.цом/хов-то-финд-тхе-стинки-партс-оф-иоур-цоде-парт-ви-цмј31ом

Одрицање одговорности 📘

Код Мириси су моје мишљење .

Цредитс 🙏

Фотографија Цхристиана Гертенбацха на Унспласх-у

Када додате заставице за тестирање, поткопавате поверење у производњу.

Вард Цуннингхам

Овај чланак је део ЦодеСмелл серије.