Test kodunun istehsala girməsinə imkan verməyin

TL;DR: isTesting və ya oxşar bayraqları əlavə etməkdən çəkinin.

Problemlər 😔

• Sızdıran abstraksiya
• Qeyri-biznes kodu çirklənməsi
• Kövrək Kod
• Uyğun olmayan davranış
• Gizli asılılıqlar
• Çətin sazlama
• Boolean bayraqları
• Etibarsız testlər
• İstehsaldan asılı kod

Həll yolları 😃

1. Ifs davranışını silin
2. Asılılıq inyeksiyasından istifadə edin
3. Xarici xidmətləri modelləşdirin (onlara istehza etməyin)
4. Ayrı-ayrı konfiqurasiyalar
5. Test məntiqini təcrid edin
6. Təmiz davranış sərhədlərini qoruyun

Refaktorinqlər ⚙️

Kontekst 💬

isTesting kimi bayraqlar əlavə etdiyiniz zaman test və istehsal kodunu qarışdırırsınız.

Bu, yalnız testlərdə aktiv olan gizli yollar yaradır.

Həmçinin, siz real istehsal kodunu əhatə etmirsiniz.

Siz səhvlərə və gözlənilməz davranışa gətirib çıxaran test davranışını istehsala göndərmə riski daşıyırsınız.

Nümunə Kod 📖

Səhv ❌

 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); } }

Düzdü 👉

 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); } }

Aşkarlama 🔍

• [x] Yarı Avtomatik

Siz isTesting , mühit == 'test' , DEBUG_MODE kimi şərti bayraqları və bu kimi deyimləri axtararaq bu qoxunu aşkar edə bilərsiniz.

Bunlar sınaq davranışının istehsal koduna sızdığını göstərir.

Teqlər 🏷️

• Test

Səviyyə 🔋

• [x] Orta

Bijection Niyə Vacibdir 🗺️

Test və istehsal kodu arasında aydın bir fərqə ehtiyacınız var.

Onları qarışdırdığınız zaman real dünya davranışı ilə proqram arasında təkbətək Bijection pozursunuz.

Mühitlər real dünya obyektləri olduğundan siz onları MAPPER- də açıq şəkildə modelləşdirməlisiniz.

AI Nəsil 🤖

Süni intellekt tərəfindən yaradılan kod tez-tez test üçün sürətli hacklərdən istifadə edərkən bu qoxunu təqdim edir.

Bəzi alətlər isTesting kimi bayraqları təklif edir, çünki onlar rahatlığı düzgün dizayndan üstün tuturlar.

AI aşkarlanması 🥃

Süni intellekt alətləri sınaq vəziyyətlərinə əsasən şərti məntiqi qeyd etmək üçün konfiqurasiya etsəniz, bu qoxunu tuta bilər.

Onları sınayın! 🛠

Unutmayın: AI köməkçiləri çoxlu səhvlər edirlər

Təklif olunan göstəriş: IsTesting metodunu silin və mühitləri modelləşdirməklə onu əvəz edin

Nəticə 🏁

isTesting bayraqlarından istifadə etməyin.

Test və istehsal məntiqini ayrı saxlamaq üçün asılılıq inyeksiyasından istifadə edin və mühitləri modelləşdirin.

Münasibətlər 👩‍❤️‍💋‍👨

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om

İmtina 📘

Kod qoxuları mənim fikrimdir .

Kredit 🙏

Unsplash -da Christian Gertenbach- ın fotoşəkili

Sınaq bayraqları əlavə etdiyiniz zaman istehsala olan inamı sarsıdırsınız.

Ward Cunningham

Bu məqalə CodeSmell Seriyasının bir hissəsidir.