Huwag hayaang lumabas ang test code sa produksyon

TL;DR: Iwasang magdagdag ng isTesting o mga katulad na flag.

Problema 😔

• Leaky abstraction
• Polusyon sa code na hindi pangnegosyo
• Marupok na Code
• Hindi pare-pareho ang pag-uugali
• Mga nakatagong dependency
• Mahirap na pag-debug
• Mga flag ng Boolean
• Mga hindi pinagkakatiwalaang pagsubok
• Code na umaasa sa produksyon

Solusyon 😃

1. Alisin ang gawi Ifs
2. Gumamit ng dependency injection
3. Magmodelo ng mga panlabas na serbisyo (Huwag kutyain sila)
4. Paghiwalayin ang mga pagsasaayos
5. Ihiwalay ang lohika ng pagsubok
6. Panatilihin ang malinis na mga hangganan ng pag-uugali

Mga refactoring ⚙️

Konteksto 💬

Kapag nagdagdag ka ng mga flag tulad ng isTesting , pinaghalo mo ang testing at production code.

Lumilikha ito ng mga nakatagong landas na aktibo lamang sa mga pagsubok.

Gayundin, hindi mo saklaw ang tunay na code ng produksyon.

Ipagsapalaran mo ang pagpapadala ng gawi sa pagsubok sa produksyon, na humahantong sa mga bug at hindi nahuhulaang gawi.

Halimbawang Code 📖

Mali ❌

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

Tama 👉

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

Pagtuklas 🔍

• [x] Semi-Awtomatiko

Made-detect mo ang amoy na ito sa pamamagitan ng paghahanap ng mga conditional na flag tulad ng isTesting , environment == 'test' , DEBUG_MODE , at mga idiom na tulad nito.

Ang mga ito ay nagpapahiwatig na ang pag-uugali ng pagsubok ay tumutulo sa code ng produksyon.

Mga tag 🏷️

• Pagsubok

Antas 🔋

• [x] Intermediate

Bakit Mahalaga ang Bijection 🗺️

Kailangan mo ng malinaw na paghihiwalay sa pagitan ng test at production code.

Kapag pinaghalo mo ang mga ito, masisira mo ang one-to-one Bijection sa pagitan ng real-world na gawi at ng programa.

Dahil ang mga kapaligiran ay mga real-world na entity kailangan mong tahasang imodelo ang mga ito sa MAPPER .

Pagbuo ng AI 🤖

Ang AI-generated code ay madalas na nagpapakilala ng amoy na ito kapag gumagamit ka ng mabilis na mga hack para sa pagsubok.

Ang ilang mga tool ay nagmumungkahi ng mga flag tulad ng isTesting dahil inuuna nila ang kadalian kaysa sa tamang disenyo.

AI Detection 🥃

Maaaring mahuli ng mga tool ng AI ang amoy na ito kung iko-configure mo ang mga ito upang i-flag ang conditional logic batay sa mga estado ng pagsubok.

Subukan Sila! 🛠

Tandaan: Maraming pagkakamali ang AI Assistants

Iminungkahing Prompt: Alisin ang IsTesting method at palitan ito sa pamamagitan ng pagmomodelo ng mga environment

Konklusyon 🏁

Iwasang gumamit ng isTesting flag.

Gumamit ng dependency injection at i-modelo ang mga kapaligiran upang panatilihing magkahiwalay ang lohika ng pagsubok at produksyon.

Mga Relasyon 👩‍❤️‍💋‍👨

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

Disclaimer 📘

Ang Code Smells ay opinyon ko.

Mga kredito 🙏

Larawan ni Christian Gertenbach sa Unsplash

Kapag nagdagdag ka ng mga flag ng pagsubok, pinapahina mo ang tiwala sa produksyon.

Ward Cunningham

Ang artikulong ito ay bahagi ng CodeSmell Series.