आप कैसे तय करते हैं कि क्या unit tests से कवर करना है और क्या integration tests से?

शाखाओं और edge cases वाले लॉजिक का unit test कीजिए: pricing rules, parsing, state machines। उन जोड़ों का integration test कीजिए जहां आपकी मान्यताएं हकीकत से टकराती हैं: डेटाबेस queries, serialization, auth middleware, third party clients। अगर किसी टेस्ट को चलने के लिए पांच mocks चाहिए, तो वह ज्यादातर आपके mocks को ही टेस्ट कर रहा है और असली फायदा integration test में है। लक्ष्य रखिए बहुत सारे तेज unit tests और उनके साथ critical रास्तों को कवर करने वाला छोटा सा integration tests का सेट।

मैं इसे इस हिसाब से बांटता हूं कि जोखिम कहां बैठा है। अगर जोखिम लॉजिक में है, शाखाएं, rounding, किसी state machine के edge cases, तो वह unit test है, और वह इतना तेज होना चाहिए कि सेव करते ही मैं पूरी file चला सकूं। अगर जोखिम किसी जोड़ पर है, जैसे मेरी SQL सच में वही लौटा रही है जो मैं समझ रहा हूं, JSON उसी तरह serialize हो रहा है जैसा client चाहता है, middleware expired token को मना कर रहा है, तो वह container में असली डेटाबेस के साथ integration test है। जो नियम मैं इस्तेमाल करता हूं वह mock की गिनती है: अगर टेस्ट चलाने के लिए मुझे चार mocks चाहिए, तो वह टेस्ट उन चार चीजों के बारे में मेरे mental model को assert कर रहा है, और प्रोडक्शन में जब वह टूटता है तो गलत ठीक वही mental model होता है। मैं इस बारे में भी ईमानदार रहने की कोशिश करता हूं कि क्या टेस्ट नहीं करता। एक पतला controller जो बस आगे भेज देता है, या कोई getter, अपने आप कवर हो जाता है और उसे अलग से टेस्ट करना बिना किसी संकेत के रखरखाव की लागत है। मुझे जो suite चाहिए वह है ढेर सारे तेज unit tests और शायद बीस integration tests, उन रास्तों पर जहां पैसा या auth शामिल है।