उपयोगकर्ता मार्गदर्शिका

1. परिचय

Fucini Coverage Studio आपके बिल्ड द्वारा पहले से बनाई गई कवरेज ट्रेसफ़ाइलों को एडिटर के अंदर प्रथम-श्रेणी कवरेज में बदल देता है — VS Code और Visual Studio में। यह पच्चीस फ़ॉर्मैट पढ़ता है, उन्हें एक कैनोनिकल Fucini मॉडल में सामान्य करता है, कई रनों को नियतात्मक रूप से मिलाता है और उसे एडिटर में ही दिखाता है — गटर, CodeLens, होवर और एक Covered Files व्यू — ताकि कोई अलग व्यूअर न हो जिसके लिए एडिटर छोड़ना पड़े। दोनों संस्करण एक रीडर साझा करते हैं: एक ही रिपोर्ट दोनों में अंक-दर-अंक वही संख्याएँ देती है। यह गाइड VS Code के नज़रिए से लिखी गई है; जहाँ Visual Studio अलग है, वहाँ In Visual Studio बॉक्स बताता है कैसे।

यह फंक्शनल-सेफ्टी वर्कफ़्लो को ध्यान में रखते हुए बनाया गया है: MC/DC कवरेज, क्षेत्र और C++ इंस्टैंशिएशन कवरेज, एक सुरक्षा-भारित समग्र स्कोर, और IEC 61508, ISO 26262 तथा DO-178C सोच के अनुरूप एक कॉन्फ़िगर करने योग्य COMPLIANT / NON-COMPLIANT निर्णय।

Screenshot pending — add assets/img/marketplace-demo.gif (see SCREENSHOTS.md).

2. इंस्टॉल और आवश्यकताएँ

• VS Code ≥ 1.88 — इस एक्सटेंशन द्वारा समर्थित न्यूनतम संस्करण — या Visual Studio 2022 या 2026, Community, Professional या Enterprise (नीचे का बॉक्स देखें)।
• एक कवरेज ट्रेसफ़ाइल जो आपका प्रोजेक्ट पहले से बनाता है (§4 देखें)।

Marketplace से, या Extensions → ⋯ → Install from VSIX… के माध्यम से .vsix से इंस्टॉल करें। एक्सटेंशन स्टार्टअप पर सक्रिय होता है और एक्टिविटी बार में Coverage आइकन जोड़ता है।

3. त्वरित प्रारंभ

1. अपने सामान्य टेस्ट वर्कफ़्लो के साथ एक कवरेज ट्रेसफ़ाइल बनाएं।
2. कमांड पैलेट (Ctrl+Shift+P) → Fucini Coverage: Load Coverage। watch.enabled चालू होने पर (डिफ़ॉल्ट), मिलान वाली फ़ाइल स्वतः लोड होती है।
3. एक कवर की गई स्रोत फ़ाइल खोलें: स्टेटस बार उसका प्रतिशत दिखाता है, Coverage व्यू भर जाता है, किसी पंक्ति पर होवर करने से उसका हिट काउंट दिखता है, और रन नेटिव Test Coverage पैनल में दिखाई देता है। अनकवर्ड पंक्तियों पर बार, हिट-काउंट हीटमैप और इनलाइन ×N काउंट एक सेटिंग की दूरी पर हैं (editorGutter.mode, hitCounts.inline)।

Screenshot pending — add assets/img/gutters.png (see SCREENSHOTS.md).

4. ट्रेसफ़ाइलें बनाना

लोड होने पर निम्न में से कोई भी स्वतः पहचाना जाता है:

C / C++ — LLVM (llvm-cov)

clang --coverage -fprofile-instr-generate -fcoverage-mapping test.c -o test
LLVM_PROFILE_FILE=test.profraw ./test
llvm-profdata merge -sparse test.profraw -o test.profdata
llvm-cov export ./test -instr-profile=test.profdata --format=json > coverage.json

llvm-cov JSON सबसे समृद्ध इनपुट है — यह लाइनों, ब्रांचों और फ़ंक्शनों के अतिरिक्त क्षेत्र, MC/DC और C++ टेम्पलेट इंस्टैंशिएशन भी वहन करता है।

C / C++ — GCC (gcov → lcov)

gcc --coverage calc.c calc_test.c -o test && ./test
lcov --capture --directory . --output-file lcov.info
# or gcovr --cobertura coverage.xml
# or skip the conversion entirely: gcovr --json coverage.json

JavaScript / TypeScript — Istanbul / nyc

nyc --reporter=json mocha        # emits coverage/coverage-final.json

Java — JaCoCo

mvn test        # emits target/site/jacoco/jacoco.xml

Ruby — SimpleCov

# .resultset.json (built-in) or coverage.json via the simplecov-json gem

Go

go test ./... -coverprofile=coverage.out    # read directly, no conversion

Python — coverage.py

coverage run --branch -m pytest && coverage json    # emits coverage.json

PHP — PHPUnit (Clover)

XDEBUG_MODE=coverage phpunit --coverage-clover clover.xml

.NET / C# — Coverlet (OpenCover)

dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover

एक नेटिव C++ प्रोजेक्ट, Visual Studio से मापा हुआ

Screenshot pending — add assets/img/vs-native-run.gif (see SCREENSHOTS.md).

5. लोडिंग और खोज

डिफ़ॉल्ट रूप से एक्सटेंशन वर्कस्पेस रूट से स्कैन करता है। इसे दो सेटिंग्स के साथ अधिक सटीक बनाएं:

{
  "fuciniCoverage.coverageFile.defaultLocation": "${workspaceFolder}/build",
  "fuciniCoverage.coverageFile.paths": [
    "coverage.json",
    "reports/*.info",
    "${env:CI_ARTIFACTS}/lcov.info",
    "https://ci.example.com/artifacts/latest/coverage.xml"
  ]
}

• प्रत्येक paths प्रविष्टि defaultLocation (या अनसेट होने पर वर्कस्पेस रूट) के सापेक्ष होती है।
• * वाली प्रविष्टि पुनरावर्ती रूप से खोजी जाती है; एक सादा फ़ाइलनाम केवल बेस फ़ोल्डर में सीधे मेल खाता है।
• जब paths खाली हो, तो एक्सटेंशन coverage.json, फिर lcov.info खोजता है, जो भी पहले मिले उसे लोड करता है।
• Pick Coverage File इन पथों के बजाय आपकी चुनी गई फ़ाइलों का उपयोग करता है — हर चयन सेट में जुड़ता है और सभी मर्ज होती हैं — जब तक आप उन्हें अनलोड न करें या ये सेटिंग्स संपादित न करें।
• वेरिएबल — हर पथ सेटिंग ${workspaceFolder}, ${workspaceFolderBasename}, ${userHome}, ${env:NAME}, ${command:id} और ${config:section.key} का विस्तार करती है। जिस वेरिएबल को एक्सटेंशन नहीं जानता, वह जैसा लिखा है वैसा ही छोड़ दिया जाता है, ताकि टाइपो ग़ायब होने के बजाय खोज लॉग में उस पथ के रूप में दिखे जिसे खोजा गया। ${command:id} पहले वह कमांड चलाता है — केवल भरोसेमंद वर्कस्पेस में, अधिकतम पाँच सेकंड के लिए — इसलिए ${command:cmake.buildDirectory} चुनी गई CMake किट के साथ चलता है।
• URL प्रविष्टियाँ — http(s):// प्रविष्टि हर लोड पर एक्सटेंशन के स्टोरेज में फ़ेच की जाती है और वहीं से लोड होती है; Coverage व्यू URL का नाम बताता है। हर फ़ेच सशर्त है (ETag / Last-Modified), इसलिए अपरिवर्तित आर्टिफ़ैक्ट कुछ डाउनलोड नहीं करता, और फ़ेच विफल होने पर आख़िरी डाउनलोड की गई प्रति लोड होती है, कारण आउटपुट में। remote.headers वेरिएबल विस्तारित करके Name: value हेडर जोड़ता है, remote.refreshMinutes टाइमर पर दोबारा फ़ेच करता है, और #lcov.info फ़्रैगमेंट फ़ॉर्मैट बताता है जब URL स्वयं किसी फ़ाइल नाम पर ख़त्म न हो।
• Ignore ग्लोब — fuciniCoverage.ignore लोड होते समय पूरी फ़ाइलें (वेंडर की गई, जनरेट की गई, तृतीय-पक्ष) रन से हटा देता है, इसलिए हर व्यू, गेट और निर्यात उनके बिना गिनता है; लोड परिणाम बताता है कि कितनी छोड़ी गईं और आउटपुट उनके नाम देता है। पैटर्न वर्कस्पेस-सापेक्ष और निरपेक्ष पथ से मिलाए जाते हैं, और बिना / वाला पैटर्न किसी भी गहराई पर फ़ोल्डर या फ़ाइल नाम से मेल खाता है, .gitignore की तरह।
• मल्टी-रूट वर्कस्पेस — हर फ़ोल्डर अपनी शर्तों पर खोजा जाता है: defaultLocation, paths, pathRemap, ignore, watch.* और remote.* प्रति फ़ोल्डर पढ़े जाते हैं, इसलिए फ़ोल्डर की अपनी .vscode/settings.json या उसकी .code-workspace प्रविष्टि लागू होती है, और प्रविष्टि में ${workspaceFolder} का अर्थ उस प्रविष्टि का अपना फ़ोल्डर है। हर फ़ोल्डर की ट्रेसफ़ाइलें एक रन में मर्ज होती हैं, Coverage व्यू फ़ाइलों को फ़ोल्डर के अनुसार समूहित करता है, और वर्कस्पेस में फ़ोल्डर जोड़ने या हटाने पर कवरेज अपने आप रीलोड होती है।
• टास्क के बाद रीलोड — watch.reloadAfterTasks उन टास्कों के नाम लेता है (tasks.json का label, या source: name जैसा Run Task सूची दिखाती है) जिनके समाप्त होने पर कवरेज रीलोड होती है, चाहे watch.enabled चालू हो या नहीं — उन बिल्ड के लिए जिनका वॉचर पीछा नहीं कर सकता। वर्कस्पेस के बाहर की निरपेक्ष paths प्रविष्टि भी पोल की जाती है, ताकि वहाँ आई फ़ाइल लोड हो।
• प्रगति जिसे रद्द किया जा सके — दस या अधिक ट्रेसफ़ाइलों का, या 8 MB या अधिक का लोड एक प्रगति सूचना के तहत चलता है जिसमें Cancel बटन है और जो पढ़ी जा रही फ़ाइल और चरण बताती है; छोटा लोड सिर्फ़ स्टेटस बार घुमाता है। रद्द करने पर पिछला रन लोड रहता है और यह बताया जाता है।

1.2026.6 से निरपेक्ष प्रविष्टि में भी वाइल्डकार्ड हो सकता है: ${workspaceFolder}/build/coverage-merged/*.lcov.info उस फ़ोल्डर की ऐसी हर फ़ाइल लोड करता है, और ** किसी भी गहराई के लिए है। पहले वाइल्डकार्ड से पहले के फ़ोल्डर वह जगह हैं जहाँ यह देखता है, और उन पर निगरानी रहती है, इसलिए बिल्ड वहाँ जो रिपोर्ट लिखता है वह अपने आप लोड होती है। Visual Studio संस्करण ऐसी प्रविष्टि को उसी तरह पढ़ता है, और 1.2026.5 से वहाँ भी सापेक्ष वाइल्डकार्ड किसी भी गहराई पर खोजा जाता है, जैसा यहाँ हमेशा से होता आया है।

जब कोई paths कॉन्फ़िगर नहीं होता, तब बेस फ़ोल्डर के नीचे मिलने वाले जाने-पहचाने रिपोर्ट नामों में से पहला लोड किया जाता है। पहले वे चार जिन्हें यह हमेशा से खोजता रहा है — coverage.json, lcov.info, coverage.out, clover.xml — फिर, 0.2026.83 से, jacoco.xml, coverage.xml, cobertura.xml, coverage.cobertura.xml, coverage.opencover.xml और coverage-final.json, और उसके बाद वे जगहें जहाँ डिफ़ॉल्ट कॉन्फ़िगरेशन लिखते हैं: coverage/ (nyc, Jest, vitest, PHPUnit, SimpleCov), target/site/jacoco/jacoco.xml (Maven), build/reports/jacoco/test/jacocoTestReport.xml (Gradle) और TestResults/*/coverage.cobertura.xml (dotnet test)। इसलिए कोई Java या .NET प्रोजेक्ट पहली बार खोलते ही अपना कवरेज दिखाता है, जैसा कि lcov प्रोजेक्ट हमेशा से करता आया है।

1.2026.3 से एक .NET सॉल्यूशन को और भी कम चाहिए: हर टेस्ट प्रोजेक्ट का TestResults/<run>/ फ़ोल्डर जाने-पहचाने स्थानों में शामिल है, केवल वर्कस्पेस फ़ोल्डर का अपना नहीं, और Microsoft के कलेक्टर की <user>_<machine>_<date>.cobertura.xml Coverlet की coverage.cobertura.xml के बगल में मिल जाती है — इसलिए जिस सॉल्यूशन के टेस्ट Visual Studio के Test Explorer में चलाए गए हों, वह पहली बार खोलते ही अपनी कवरेज दिखाता है, हर रन फ़ोल्डर लोड होता है, और मर्ज हर फ़ाइल पर सबसे नए रन की बात रखता है। और fuciniCoverage.ignore.generated, जो डिफ़ॉल्ट रूप से चालू है, डिज़ाइनर और जनरेट की गई फ़ाइलों — *.Designer.cs, *.g.cs, *.generated.cs, *.razor.g.cs, AssemblyInfo, ग्लोबल usings, Migrations/ और obj/ — को ignore लागू होने से पहले हर टोटल, पेज और एक्सपोर्ट से बाहर रखता है, ताकि एक जनरेट की गई तालिका जिसे कोई टेस्ट नहीं करता, सॉल्यूशन का गेट न छीन ले।

टोकन के पीछे रखा CI आर्टिफ़ैक्ट, हर पंद्रह मिनट पर दोबारा जाँचा गया — टोकन एनवायरनमेंट में रहता है, settings.json में कभी नहीं:

{
  "fuciniCoverage.coverageFile.paths": [
    "https://ci.example.com/api/builds/latest/artifacts/coverage#lcov.info"
  ],
  "fuciniCoverage.remote.headers": ["Authorization: Bearer ${env:CI_TOKEN}"],
  "fuciniCoverage.remote.refreshMinutes": 15
}

Screenshot pending — add assets/img/remote-tracefile.png (see SCREENSHOTS.md).

रीलोड जान-बूझकर चुप है — हर बिल्ड के बाद एक डायलॉग ऐसा प्रश्न है जिसका एक ही उत्तर है। जो चुप नहीं है वह Coverage आइकन है: जब तक व्यू आपके सामने नहीं है, वह उन ट्रेसफ़ाइलों की संख्या रखता है जिन्हें दोबारा पढ़ा गया, और उसका टूलटिप उनके नाम बताता है। व्यू खोलिए और गिनती चली जाती है।

Screenshot pending — add assets/img/coverage-badge.gif (see SCREENSHOTS.md).

वे फ़ाइलें जो कभी नहीं गिनी जानी चाहिए, ट्रेसफ़ाइल उनके बारे में चाहे जो कहे:

{
  "fuciniCoverage.ignore": ["vendor/**", "**/*.generated.ts", "build/**"]
}

टेस्ट टास्क समाप्त होने पर रीलोड, ऐसे बिल्ड के लिए जिसका फ़ाइल वॉचर पीछा नहीं कर सकता — सिमलिंक किए गए आउटपुट ट्री को बदल देने वाला रन, नेटवर्क शेयर पर रिपोर्ट, अपनी फ़ाइल को पोस्ट-प्रोसेस करने वाला कवरेज चरण:

{
  "fuciniCoverage.watch.reloadAfterTasks": ["npm: test", "coverage-report"]
}

6. रन मर्ज करना

हर मौजूदा paths प्रविष्टि लोड होकर एक रन में विलय हो जाती है। विलय निर्धारक है — परिणाम लोड करने के क्रम पर निर्भर नहीं करता — और एक से अधिक ट्रेसफ़ाइल द्वारा मापी गई फ़ाइल अपने आँकड़े उस ट्रेसफ़ाइल से लेती है जिसका डिस्क पर mtime सबसे नया है: किसी मॉड्यूल का अपना पुनः-रन उस व्यापक, पुराने रन की बातों में जुड़ने के बजाय उन्हें बदल देता है। कवरेज दृश्य दिखाता है कि इससे क्या हुआ: हर फ़ाइल पंक्ति बताती है कि उसके आँकड़े किस ट्रेसफ़ाइल से आए, जहाँ उन आँकड़ों ने पुरानी रिपोर्ट को पीछे छोड़ा वहाँ बैज रेखांकित होता है, ट्री के ऊपर हर ट्रेसफ़ाइल पंक्ति गिनती है कि उसकी कितनी फ़ाइलें पीछे छूटीं या दूसरों को पीछे छोड़ा, और ट्रेसफ़ाइल पंक्ति पर क्लिक करने से उसकी फ़ाइलें ट्री में तब तक हाइलाइट रहती हैं जब तक उस पर दोबारा क्लिक न किया जाए (coverageView.mergedMarks रेखांकन और हाइलाइट बंद करता है)।

Screenshot pending — add assets/img/four-reports-one-file.svg (see SCREENSHOTS.md).

एक मर्ज किए गए रन में छह पारंपरिक मेट्रिक से अधिक हो सकते हैं, और हर एक उस रिपोर्ट से आता है जो उसे मापती है: लाइनें, फ़ंक्शन, रीजन, ब्रांच, MC/DC और इंस्टैंशिएशन के साथ-साथ फ़ंक्शन कॉल, ऑब्जेक्ट कोड और म्यूटेशन स्कोर। Coverage व्यू हर उस मेट्रिक के लिए एक कॉलम दिखाता है जो रन में मौजूद है — और जो मौजूद नहीं है उसके लिए कोई कॉलम नहीं; कॉलम आपके स्कोर में उनके भार के क्रम में आते हैं, सबसे भारी पहले, और किसी भी चौड़ाई पर दिखते हैं — जो नहीं समाता वह गायब होने के बजाय बगल में स्क्रॉल हो जाता है; इसे निचले पैनल में खींचें और यह एक तालिका बन जाता है। स्टेटस बार के कार्ड, HTML रिपोर्ट और CSV तथा Markdown एक्सपोर्ट इसी नियम का पालन करते हैं: रिपोर्ट में जो है वह दिखाया जाता है, और जो नहीं है उसे शून्य के रूप में छापने के बजाय छोड़ दिया जाता है।

Screenshot pending — add assets/img/coverage-view-editor.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/coverage-view-columns.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/workspace-overview.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-workspace-overview.gif (see SCREENSHOTS.md).

कोई फ़ाइल किस रिपोर्ट से आती है

जब कई लोड की गई रिपोर्टें एक ही फ़ाइल को मापती हैं, तो सबसे नई रिपोर्ट उसे पूरी तरह जीत लेती है — यह तब सही है जब किसी मॉड्यूल का अपना दोबारा चलाया गया रन किसी पुराने, व्यापक रन की बात को बदल देता है। यह तब गलत है जब रिपोर्टें जानबूझकर एक ही कोड मापती हैं: तब एडिटर हर बिल्ड के साथ उनके बीच पलटता रहता है, और हर रिपोर्ट कहानी का केवल एक हिस्सा बताती है। coverageFile.sources हर फ़ाइल के लिए बताता है कि इसके बजाय क्या करना है। तीन स्थितियों में इसकी ज़रूरत पड़ती है:

• एक रिपोर्ट बेहतर है। llvm-cov की coverage.json में MC/DC होता है, जबकि उसी बिल्ड की GCC gcov.info में केवल पंक्तियाँ और ब्रांच: coverage.json चुनें, और दूसरी को उन कुछ फ़ाइलों के लिए रखें जिन्हें केवल GCC बिल्ड करता है।
• एक बिल्ड के कई टेस्ट सुइट। यूनिट टेस्ट, इंटीग्रेशन टेस्ट और हार्डवेयर-इन-द-लूप, हर एक अपनी रिपोर्ट लिखता है; अकेले में हर रिपोर्ट उन पंक्तियों को छोड़ देती है जो दूसरों ने चलाईं। मिलाएँ, union: कोई पंक्ति वहाँ कवर है जहाँ किसी भी रिपोर्ट ने उसे चलाया, और गिनतियाँ जुड़ जाती हैं।
• एक कोडबेस, दो कंपाइलर। clang और GCC से बने वही सोर्स टूलचेन-विशिष्ट कोड में अलग-अलग रास्ते लेते हैं — कहीं एक इंट्रिन्सिक, कहीं एक पोर्टेबल फ़ॉलबैक — और हर रिपोर्ट कहती है कि दूसरा आधा कभी नहीं चला। मिलाएँ, agree: कोई पंक्ति तभी कवर है जब उसे मापने वाली हर रिपोर्ट ने उसे चलाया हो, और जिन पंक्तियों पर वे असहमत हैं वे टील रंग में चिह्नित होती हैं। क्रॉस-कंपाइलर जाँच यही सवाल पूछती है: मैं जो भी बिल्ड शिप करता हूँ, उन सभी ने असल में क्या चलाया?

नियम आपको शायद ही कभी हाथ से लिखने पड़ते हैं। Coverage व्यू में किसी फ़ाइल पर राइट-क्लिक करें और Choose Coverage Source... चुनें (या खुली फ़ाइल पर Choose Coverage Source for This File... चलाएँ): यह फ़ाइल को मापने वाली हर रिपोर्ट को उसकी अपनी पंक्तियों, ब्रांच और MC/DC के साथ सूचीबद्ध करता है, फिर Combine them — agree और Combine them — union; एक चुनें और बताएँ कि यह फ़ाइल, उसके फ़ोल्डर या किसी पैटर्न पर लागू हो। Clear Coverage Source for This File... नियम को फिर से हटा देता है। सेटिंग्स में हर नियम फ़ाइलों पर एक glob, रिपोर्ट पर एक glob (/ के बिना पैटर्न रिपोर्ट के फ़ाइल नाम से मेल खाता है, {a,b} कई नाम देता है) और मिलाने के लिए "combine": "agree" या "union" होता है। पहला नियम जिसकी फ़ाइलें मेल खाती हैं और जिसकी रिपोर्ट फ़ाइल को मापती है, वही तय करता है; जिस फ़ाइल को केवल एक रिपोर्ट मापती है, वह उससे कभी नहीं छीनी जाती। मिलाई गई फ़ाइल की ब्रांच, MC/DC और क्षेत्र उस रिपोर्ट से आते हैं जिसमें वे सबसे अधिक हों। coverageFile.mergeStrategy: "order" उन फ़ाइलों को, जिनके लिए कोई नियम नहीं बोलता, समय के बजाय coverageFile.paths के क्रम से तय करता है।

{
  "fuciniCoverage.coverageFile.paths": ["clang.json", "gcc/bits.gcov.json.gz"],
  "fuciniCoverage.coverageFile.sources": [
    { "files": "src/**", "report": "{clang.json,bits.gcov.json.gz}", "combine": "agree" }
  ]
}

आप क्या देखते हैं: Coverage व्यू में फ़ाइल की पंक्ति उस रिपोर्ट का नाम बताती है जिससे उसके आँकड़े आते हैं, या, मिलाने पर, हर रिपोर्ट और मोड, विवादित पंक्तियों के लिए ≠ n के साथ। गटर और एनोटेटेड सोर्स उन पंक्तियों को टील रंग में चिह्नित करते हैं और बताते हैं कि किस रिपोर्ट ने उन्हें कितनी बार चलाया। स्टेटस बार का होवर कार्ड खुली फ़ाइल का स्रोत बताता है और, पूरे रन के लिए, लागू नियम और यह कि बाकी फ़ाइलें कैसे तय हुईं। डेमो का samples/c-cross-check दो-कंपाइलर वाला मामला है, खोलने के लिए तैयार। Visual Studio भी यह सब करता है: Coverage व्यू की किसी पंक्ति पर Choose Coverage Source..., और Tools > Coverage Studio के अंतर्गत Choose और Clear Coverage Source for This File...।

स्रोत चुनना और मिलाना सशुल्क प्लान का हिस्सा है। Community पर हर फ़ाइल सबसे नई रिपोर्ट जीतती है, जैसा किसी नियम के न होने पर होता है, और सेटिंग्स में मौजूद नियम को चुपचाप अनदेखा करने के बजाय अप्रयुक्त बताया जाता है।

7. पाथ रीमैपिंग

CI अक्सर पूर्ण बिल्ड-मशीन पाथ रिकॉर्ड करता है जो आपके वर्कस्टेशन पर मौजूद नहीं होते। उन्हें क्रमबद्ध नियमों से फिर से लिखें:

{
  "fuciniCoverage.pathRemap": [
    { "from": "/builds/ci/project", "to": "${workspaceFolder}" },
    { "from": "\\\\", "to": "/" }
  ]
}

नियम क्रम में लागू होते हैं; प्रति उपसर्ग पहला मिलान जीतता है। इसका उपयोग Windows/Unix सेपरेटर अंतर को दूर करने या एक कंटेनर पाथ को अपने चेकआउट पर मैप करने के लिए करें।

नियम आपको शायद ही कभी ख़ुद लिखना पड़े। सबसे आम “लोड तो हुआ पर कुछ जलता नहीं” वह ट्रेसफ़ाइल है जिसके पथ किसी कंटेनर या CI चेकआउट से आते हैं (/build/src/a.c, /home/runner/work/repo/repo/src/a.c, C:\agent\_work\1\s\src\a.c) जबकि वर्कस्पेस में src/a.c है। जब कोई लोड फ़ाइलों को बेमेल छोड़ता है, तो एक्सटेंशन फ़ाइल नाम वर्कस्पेस में खोजता है, वह उपसर्ग नियम निकालता है जो उनमें से सबसे अधिक को समझाता है, उसे [FUCINI_REMAP_002] के रूप में लॉग करता है, और लोड परिणाम Apply Suggested Remap देता है — एक क्लिक नियम को fuciniCoverage.pathRemap में जोड़कर रीलोड करता है। Suggest Path Remap Rule वही विश्लेषण पैलेट से माँग पर चलाता है। क्लिक के बिना कुछ नहीं लिखा जाता।

to में ${workspaceRoot} हो सकता है, जो उस वर्कस्पेस फ़ोल्डर के लिए खड़ा है जिसमें ट्रेसफ़ाइल है; मल्टी-रूट वर्कस्पेस में यह पहले वही फ़ोल्डर आज़माता है, फिर हर दूसरा फ़ोल्डर जिसमें वह फ़ाइल निकलती है। नियम स्वयं प्रति फ़ोल्डर पढ़े जाते हैं, इसलिए मल्टी-रूट वर्कस्पेस का हर रूट अपने नियम रख सकता है।

8. एडिटर में कवरेज

• गटर और रूलर — डिफ़ॉल्ट रूप से एडिटर का अपना गटर केवल निष्कर्ष दिखाता है: MC/DC बार, पिछले-रन-के-बाद वाले त्रिकोण, संपादित-पंक्ति बिंदु। editorGutter.mode केवल-अनकवर्ड बार या हिट-काउंट हीटमैप जोड़ता है (नीचे); पूरी फ़ाइल का रंग-कोडित दृश्य Annotated Source है।
• फ़ंक्शन CodeLens — प्रत्येक फ़ंक्शन के ऊपर कवरेज %; इसकी पहली अनकवर्ड लाइन पर जाने के लिए क्लिक करें। codeLens.enabled से टॉगल करें।
• ब्रांच और MC/DC होवर — प्रति-आर्म लिया गया/नहीं लिया गया गणना और प्रति-स्थिति वेक्टर तालिका के लिए किसी निर्णय लाइन पर होवर करें। mcdcGutter.enabled से रंगीन मार्जिन बार सक्षम करें।
• डेड-कोड चेतावनियाँ — मापने योग्य लाइनों और शून्य कवरेज वाले फ़ंक्शन Problems पैनल में फ़्लैग किए जाते हैं (deadCode.enabled)।
• Next / Previous Uncovered — अंतरालों के बीच कूदें।
• स्टेटस बार — एक रन-व्यापी $(dashboard) NN% आइटम और प्रति-फ़ाइल आइटम, दोनों समग्र स्कोर के अनुसार रंग-कोडित; पूर्ण मेट्रिक्स तालिका के लिए होवर करें।
• एक्सप्लोरर बैज — प्रति-फ़ाइल और प्रति-फ़ोल्डर कवरेज बैज, होवर पर मेट्रिक विवरण के साथ। डिफ़ॉल्ट रूप से बंद: explorerBadges.enabled से इन्हें चालू करें।
• पिछले रन के बाद — पिछले रन में निष्पादित और इस रन में न हुई हर पंक्ति पर लाल त्रिकोण, उलटे मामले में हरा, ओवरव्यू रूलर और होवर पर हिट संख्या के साथ।
• संपादित बफ़र — संपादन के साथ हर चिह्न, होवर और CodeLens पाठ के संग चलता है, और फिर से लिखी पंक्ति से हट जाता है, जहाँ धूसर बिंदु कारण बताता है।
• इनलाइन हिट काउंट — hitCounts.inline हर उस पंक्ति के बाद ×12 लिखता है जिस पर कोई स्टेटमेंट शुरू होता है, ×0 समेत: वही संख्या जो हमेशा से होवर पर थी, बिना होवर किए। Toggle Inline Hit Counts इसे पलटता है; स्टेटस-बार मेनू इसे दिखाएँ या छिपाएँ के रूप में देता है, जो भी लागू हो।
• प्रति-पंक्ति Problems प्रविष्टियाँ — problems.perLine खुले दस्तावेज़ में कभी न चली पंक्तियों के हर सटे हुए ब्लॉक पर एक Information डायग्नोस्टिक रखता है, एडिटर में लहरदार रेखा के साथ (चालीस पंक्तियों का डेड फ़ंक्शन एक प्रविष्टि है, चालीस नहीं) और, uncoveredAndPartial के रूप में, हर उस पंक्ति पर जिसकी कोई ब्रांच आर्म कभी नहीं ली गई। संपादन के साथ प्रविष्टियाँ अपनी पंक्तियों के संग चलती हैं और दस्तावेज़ बंद होते ही चली जाती हैं; problems.enabled के पीछे की प्रति-फ़ाइल प्रविष्टि अपरिवर्तित है।
• पंक्ति का रंग — lineHighlight गटर जो चिह्नित करता है उसके लिए पंक्तियों के पीछे पारभासी रंग रखता है (uncovered, या चली हुई पंक्तियों के लिए भी heatmap)। अपनी सेटिंग, ताकि खाली जगहें रँगी रहें और गटर साफ़ रहे, या इसका उलटा।
• अवलोकन रूलर — overviewRuler स्क्रॉलबार की पट्टी का निर्णय गटर से स्वतंत्र रूप से करता है: follow (पट्टियों के साथ, पहले की तरह), uncovered (हमेशा, ताकि गटर बंद रहते हुए भी स्क्रॉलबार खाली जगहों का नक्शा दिखाए) या off।
• किस ट्रेसफ़ाइल ने पंक्ति कवर की — कई रिपोर्टें विलय होने पर हिट-गिनती वाला होवर किसने कवर किया: और उस पंक्ति को कवर करने वाली हर रिपोर्ट के साथ समाप्त होता है, जिसमें lcov के TN: से सुइट का नाम भी शामिल है; Coverage दृश्य में ट्रेसफ़ाइल की पंक्ति पर क्लिक करने से उसके द्वारा दी गई पंक्तियाँ हर खुले संपादक में रोशन होती हैं।

Screenshot pending — add assets/img/codelens-hover.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/codelens-crap.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/jump-between-gaps.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/explorer-badges.png (see SCREENSHOTS.md).

एडिटर गटर मोड

editorGutter.mode तय करता है कि एडिटर का अपना गटर कवरेज के बारे में क्या दिखाता है, उन निष्कर्षों के ऊपर जो वह हमेशा दिखाता है। off (डिफ़ॉल्ट) केवल वही हैं। uncovered हर उस पंक्ति पर बार लगाता है जो कभी नहीं चली और हर उस पंक्ति पर एम्बर बार जिसकी कोई ब्रांच आर्म कभी नहीं ली गई, और कवर्ड पंक्तियों पर कुछ नहीं, ताकि हरी दीवार तीन लाल पंक्तियों को छिपा न ले। coverage हर कवर्ड पंक्ति पर हरा बार जोड़ता है, ताकि पूरी फ़ाइल कलर स्केल के रंगों में लाल, एम्बर और हरी पढ़ी जाए। heatmap इसके बजाय हर निष्पादित पंक्ति पर एक गर्म रंग जोड़ता है, जितनी बार चली उतना गहरा — यह दिखाता है कि पंक्ति कितनी बार चली, न कि वह कवर्ड है या नहीं, इसलिए 100% वाली फ़ाइल वहाँ पीली से भूरी होती है, कभी हरी नहीं। Choose Editor Gutter Mode... पैलेट या स्टेटस-बार मेनू से एक चुनता है; स्टेटस बार के दाईं ओर का मोड बटन, या Alt+G, एक बार दबाने पर अगले पर ले जाता है (statusBar.showModeToggle बटन छिपाता है)। दोनों सेटिंग लिखते हैं। उदाहरण अनकवर्ड बार और इनलाइन काउंट एक साथ चालू करता है:

{
  "fuciniCoverage.editorGutter.mode": "uncovered",
  "fuciniCoverage.hitCounts.inline": true
}

Screenshot pending — add assets/img/gutters.png (see SCREENSHOTS.md).

हीटमैप फ़ाइल के सापेक्ष होता है। किसी लाइन का शेड उसकी गिनती की तुलना उसी फ़ाइल की सबसे अधिक चलने वाली लाइन से करता है, लघुगणकीय पैमाने पर, पाँच चरणों में — इसलिए हज़ार बार चलने वाली लूप बॉडी और दो बार चलने वाला फ़ंक्शन दोनों दिखाई देते हैं, एक दूसरे को दबा नहीं देता, और जिस फ़ाइल में सब कुछ ठीक एक बार चला हो वह एकसमान फीकी नहीं बल्कि एकसमान गर्म रंग की दिखती है। डार्क थीम पर रंग-क्रम मंद जैतूनी से चटक नारंगी तक जाता है, लाइट थीम पर हल्के पीले से भूरे तक: दोनों ही स्थितियों में अधिक रंग का अर्थ अधिक निष्पादन है, और लाल रंग उन लाइनों के लिए सुरक्षित रहता है जो कभी नहीं चलीं। lineHighlight: "heatmap" वही शेड कोड के पीछे हल्की परत के रूप में लगाता है, और hitCounts.inline लाइन के बाद सटीक गिनती लिखता है।

{
  "fuciniCoverage.editorGutter.mode": "heatmap",
  "fuciniCoverage.lineHighlight": "heatmap",
  "fuciniCoverage.hitCounts.inline": true
}

Screenshot pending — add assets/img/heatmap-dark.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/heatmap-light.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/heatmap.gif (see SCREENSHOTS.md).

रंग आपके हैं। colorScale.lowColor, midColor और highColor गटर, पंक्तियों के पीछे के रंग और हर प्रतिशत के लाल, एम्बर और हरे को रँगते हैं; heatmap.colors और heatmap.colorsDark लाइट और डार्क थीम के लिए हीटमैप के पाँच शेड रखते हैं, सबसे कम चली पंक्ति से सबसे अधिक चली पंक्ति तक। सेटिंग्स पेज कुछ भी सहेजने से पहले परिणाम दिखाता है: Colour scale के नीचे, पंक्तियाँ स्क्रॉल होते समय एक पूर्वावलोकन दिखता रहता है — अपने दो पिवट के साथ ग्रेडिएंट, अपने-अपने रंगों में कुछ प्रतिशत, और coverage मोड और हीटमैप में रँगे एक छोटे लाइट और एक छोटे डार्क एडिटर — और रंग चुनते ही यह फिर से रँग जाता है।

{
  "fuciniCoverage.heatmap.colors": ["#e3f2fd", "#90caf9", "#42a5f5", "#1e88e5", "#0d47a1"]
}

लाइन का वह हिस्सा जो कभी नहीं चला

कोई लाइन या तो कवर होती है या नहीं होती, जबकि सच्चाई अक्सर इन दोनों के बीच होती है: return x > hi ? hi : x; चली, पर उसकी hi वाली शाखा कभी नहीं चली। lineHighlight चालू होने पर, चली हुई लाइन का कभी न चला हिस्सा एडिटर में रंग से दिखाया जाता है — हर उस फ़ॉर्मेट के लिए जिसमें कॉलम रेंज होती हैं (llvm-cov, Istanbul, Go, dotnet-coverage) — ये वही स्पैन हैं जिन्हें एनोटेटेड सोर्स चिह्नित करता है। केवल उन लाइनों पर जो चली हैं: जो लाइन कभी नहीं चली वह तो पहले से ही पूरी की पूरी चिह्नित है। C++ टेम्पलेट वहाँ चला हुआ गिना जाता है जहाँ किसी भी इंस्टैंशिएशन ने उसे चलाया हो; हर इंस्टैंशिएशन ने क्या किया, यह इंस्टैंशिएशन मेट्रिक बताता है।

Screenshot pending — add assets/img/partial-line.png (see SCREENSHOTS.md).

किन टेस्ट ने यह लाइन चलाई

कुछ रिपोर्ट केवल यह नहीं बतातीं कि लाइन चली, बल्कि यह भी कि किन टेस्ट ने उसे चलाया: .coveragerc में dynamic_context = test_function के साथ coverage json --show-contexts से लिखी गई coverage.py, -coverbytest के साथ एकत्र की गई OpenCover, और प्रति टेस्ट एक सेक्शन (TN:) में लिखी गई lcov ट्रेसफ़ाइल, जिसके सेक्शन जोड़कर एक रिकॉर्ड बनता है जिसमें हर लाइन के साथ टेस्ट होते हैं। लाइन की शुरुआत पर होवर करें, जहाँ हिट काउंट होता है, और टेस्ट के नाम दिखते हैं — क्लास और मेथड तक छोटे किए हुए, पहले पाँच नाम से और बाक़ी गिनती के रूप में; फ़ंक्शन का CodeLens बताता है कि कितने टेस्ट ने उसे चलाया। Show Tests That Ran This Line — Command Palette, एडिटर का कॉन्टेक्स्ट मेनू, Visual Studio में Tools → Coverage Studio या Ctrl+Shift+U, T — उन्हें सूचीबद्ध करता है, सबसे व्यस्त पहले, और जिसे आप चुनें उसे वर्कस्पेस में वहाँ खोलता है जहाँ वह लिखा है। एक dotnet test रन यह नहीं बता सकता कि किस टेस्ट ने क्या चलाया; testRun.perTest सेट करें और Run Tests with Coverage टेस्ट क्लासों को सूचीबद्ध कर उन्हें एक-एक करके चलाता है, हर रिपोर्ट पर उसकी क्लास का टैग लगाकर, ताकि होवर, लेंस और कमांड .NET के लिए भी जवाब दे सकें। यह जानकारी प्रति फ़ाइल रखी जाती है, इसलिए ऐसी रिपोर्ट के साथ मर्ज होने पर भी बनी रहती है जिसे टेस्ट के बारे में कुछ पता नहीं।

{
  "fuciniCoverage.testRun.perTest": true
}

# .coveragerc
[run]
dynamic_context = test_function

coverage run -m pytest && coverage json --show-contexts

Screenshot pending — add assets/img/tests-per-line.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/tests-for-line.gif (see SCREENSHOTS.md).

चिह्नों पर पास या फ़ेल

कवर्ड लाइन एक-सी दिखती है, चाहे उसका टेस्ट पास हुआ हो या नहीं। जहाँ रिपोर्ट बताती है कि किन टेस्ट ने कोई लाइन चलाई और रनर की रिज़ल्ट फ़ाइल बताती है कि वे कैसे समाप्त हुए, वहाँ जिस लाइन को किसी विफल टेस्ट ने चलाया उसकी शुरुआत में एक लाल बार और ओवरव्यू रूलर में एक पट्टी लगती है; उसका होवर विफल टेस्ट के नाम बताता है, और Show Tests That Ran This Line ऐसे हर टेस्ट के आगे failed लिखता है। जब कोई टेस्ट लाल हो, तो देखने की जगह वह कोड है जिससे होकर वह गुज़रा। नतीजे हर लोड पर हर रिपोर्ट के फ़ोल्डर से पढ़े जाते हैं — कोई भी .trx, और वे नाम जो JUnit राइटर इस्तेमाल करते हैं (TEST-*.xml, junit*.xml, test-results*.xml) — और testResults.paths से भी, जिसमें फ़ोल्डर के सापेक्ष पथ या ग्लॉब दिए जाते हैं। Run Tests with Coverage dotnet test से रिपोर्ट के बगल में एक test-results.trx माँगता है, इसलिए testRun.perTest चालू होने पर कुछ भी सेट अप नहीं करना पड़ता। testResults.enabled नतीजों का यह पढ़ना बंद कर देता है।

{
  "fuciniCoverage.testResults.paths": ["build/test-results/**/*.xml", "reports/junit.xml"]
  }

Screenshot pending — add assets/img/pass-fail.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-pass-fail.gif (see SCREENSHOTS.md).

वे टेस्ट जिन पर किसी बदलाव का असर पड़ता है

पूरा रन जिस सवाल का जवाब धीरे-धीरे देता है, Run Tests Affected by My Changes… उसका जवाब तुरंत देता है: सारे टेस्ट में से कौन-से उस कोड से होकर गुज़रे जिसे मैंने अभी संपादित किया? git से testImpact.baseRef के मुक़ाबले वर्किंग ट्री का डिफ़ माँगा जाता है — डिफ़ॉल्ट रूप से HEAD, यानी वह जो अभी कमिट नहीं हुआ है; origin/main, उस सब के लिए जो ब्रांच बदलती है — और जिन टेस्ट ने कोई बदली हुई लाइन चलाई वे सूचीबद्ध होते हैं, सबसे पहले वह जिसने बदलाव का सबसे बड़ा हिस्सा चलाया। किसी टेस्ट को चुनने पर वह खुल जाता है। जहाँ रिपोर्टें प्रति-टेस्ट रन (testRun.perTest) से आई हैं, वहाँ पहली प्रविष्टि केवल उन्हीं टेस्ट को चलाती है, हर क्लास को उसकी अपनी रिपोर्ट में, ताकि बाक़ी हर क्लास की रिपोर्ट बनी रहे और टोटल पूरे सूट के ही रहें। जिस टेस्ट ने केवल किसी जोड़े गए या हटाए गए हिस्से के नीचे की लाइनें चलाईं, वह भी सूचीबद्ध होता है: वरना उसकी रिपोर्ट ग़लत लाइनों के नाम देती।

Screenshot pending — add assets/img/test-impact.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-test-impact.gif (see SCREENSHOTS.md).

टेस्ट का सबसे छोटा समूह जो फिर भी हर लाइन चलाता है

Show Minimal Test Set… उन्हीं प्रति-टेस्ट लाइनों से दो सवालों के जवाब देता है: कौन-से थोड़े-से टेस्ट फिर भी हर वह लाइन चलाएँगे जो सूट चलाता है — कमिट से पहले के झटपट रन के लिए — और कौन-से टेस्ट ऐसी कोई लाइन नहीं चलाते जिसे कोई दूसरा टेस्ट पहले से न चलाता हो। चुने गए टेस्ट पहले आते हैं, हर एक के साथ वे लाइनें जो वह जोड़ता है और वे लाइनें जो केवल वही चलाता है; फिर बाक़ी टेस्ट, हर एक पर यह चिह्न कि वह कुछ नहीं जोड़ता। चुनाव ग्रीडी तरीक़े से होता है — पहले वह टेस्ट जो सबसे ज़्यादा लाइनें चलाता है, फिर वह जो उसमें सबसे ज़्यादा जोड़ता है — इसलिए यह सबसे छोटे सेट के क़रीब होता है और हर बार वही रहता है। लाइनों के हिसाब से अनावश्यक होने का मतलब यह नहीं कि टेस्ट अपनी जाँच के हिसाब से भी अनावश्यक है: जो टेस्ट कोई लाइन नहीं जोड़ता, वह फिर भी अकेला ऐसा टेस्ट हो सकता है जो उन लाइनों पर किसी मान को जाँचता है। सूची बताती है कि सूट की छँटाई करते समय कहाँ देखना है, यह कभी नहीं कि क्या हटाना है।

Screenshot pending — add assets/img/minimal-test-set.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-minimal-test-set.png (see SCREENSHOTS.md).

यह टेस्ट चलाएँ, कवरेज के साथ

कर्सर को किसी टेस्ट में रखें और Run This Test with Coverage चलाएँ — Command Palette, एडिटर का कॉन्टेक्स्ट मेनू, Visual Studio में Tools → Coverage Studio या Ctrl+Shift+U, R — और अकेला वही टेस्ट कवरेज चालू करके चलता है: वह टेस्ट मेथड जिसमें कर्सर है, या टेस्ट क्लास या describe ब्लॉक जब कर्सर मेथडों के बीच हो, या फ़ाइल जब वह हर क्लास के ऊपर हो। कर्सर के नीचे क्या है, यह टेक्स्ट से पढ़ा जाता है, इसलिए यह C#, VB और F# ([Fact], [Test], [TestMethod] और इन जैसे), JavaScript और TypeScript (it, test, describe) और Python (def test_…) के लिए काम करता है, चाहे कोई भी लैंग्वेज सर्विस इंस्टॉल हो। फ़ोल्डर की रेसिपी उस तक सीमित कर दी जाती है — dotnet test --filter "FullyQualifiedName~…", jest या vitest <file> -t "…", एक pytest नोड id — और उसने जो लिखा वह किसी भी रन की तरह लोड होता है; जो रनर सीमित नहीं किया जा सकता वह ऐसा कह देता है और Run Tests with Coverage उन सबको चलाता है।

Screenshot pending — add assets/img/run-this-test.gif (see SCREENSHOTS.md).

Go और Rust। Go फ़ाइल में कर्सर वाला func TestXxx (या Fuzz…, Example…) अकेला चलता है, अपने ही पैकेज में और अपने सटीक नाम से — go test ./pkg/calc -run "^TestTotal$" — और कर्सर किसी टेस्ट के बाहर हो तो फ़ाइल का पैकेज चलता है। Rust फ़ाइल में #[test] फ़ंक्शन क्रेट में अपने पथ से --exact के साथ चलता है; कर्सर किसी mod में हो और किसी टेस्ट में न हो, तो उस मॉड्यूल के टेस्ट चलते हैं; tests/ के नीचे का इंटीग्रेशन टेस्ट अपनी ही बाइनरी में चलता है (--test api)। रनर को केवल उसकी अपनी भाषा की फ़ाइलें सौंपी जाती हैं: Go फ़ोल्डर में रखी TypeScript फ़ाइल को जवाब में एक वाक्य मिलता है, न कि ऐसा रन जो कुछ नहीं चलाता।

हर सेव के बाद कवरेज

testRun.onSave चालू होने पर, किसी सोर्स को सेव करने से सेव के कुछ ही क्षण बाद उसे कवर करने वाले टेस्ट कवरेज के साथ चलते हैं, और गटर उसके पीछे-पीछे बदलता है। .NET सॉल्यूशन के लिए सेव की गई फ़ाइल का प्रोजेक्ट .csproj ग्राफ़ से खोजा जाता है और केवल वे टेस्ट प्रोजेक्ट चलाए जाते हैं जो उसे संदर्भित करते हैं — सीधे, या अन्य प्रोजेक्टों के ज़रिये — हर एक के लिए एक dotnet test <project>; कोई भी अन्य रनर अपनी पूरी रेसिपी चलाता है; जिस फ़ाइल का कोई प्रोजेक्ट मालिक नहीं और जिसे कोई रिपोर्ट नहीं मापती, उसके लिए कुछ नहीं चलता। लगातार कई सेव एक ही रन हैं, और पहले से चल रहा रन बाधित नहीं होता। बाक़ी वैसा ही है जैसा Run Tests with Coverage करता है: टर्मिनल, Output पैन, लोड की गई रिपोर्ट। डिफ़ॉल्ट रूप से बंद — यह चुनने की आदत है, खोज निकालने का डिफ़ॉल्ट नहीं।

{
  "fuciniCoverage.testRun.onSave": true
}

Screenshot pending — add assets/img/coverage-on-save.gif (see SCREENSHOTS.md).

खुद ऐप, कवरेज के साथ

टेस्ट रन बताता है कि टेस्ट कौन-सा कोड चलाते हैं। कोई व्यक्ति जो कोड चलाता है — रिलीज़ से पहले स्क्रीनों पर क्लिक करते हुए, किसी ग्राहक के कदम दोहराते हुए — वह भी कवरेज है, और Run App with Coverage… उसे इकट्ठा करता है। फ़ोल्डर का .NET ऐप — कोई Exe, कोई WinExe, कोई वेब या वर्कर प्रोजेक्ट, टेस्ट प्रोजेक्ट कभी नहीं; कई हों तो आप उनमें से एक चुनते हैं — Microsoft के dotnet-coverage के तहत अपने अलग कंसोल में शुरू किया जाता है, ताकि कंसोल ऐप में टाइप किया जा सके, और तब तक चलता है जब तक आप उसे बंद न करें। ऐप में आप जिस-जिस हिस्से से गुज़रे, वह फिर किसी भी रन की तरह लोड होता है, और कवरेज सेशन में वह उसमें जुड़ जाता है जो टेस्ट ने चलाया। ऐप चाहे जैसे समाप्त हुआ हो, रन को इस कारण विफल नहीं माना जाता। इसके लिए यह टूल एक बार इंस्टॉल करना होता है: dotnet tool install --global dotnet-coverage।

Screenshot pending — add assets/img/run-app.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-run-app.gif (see SCREENSHOTS.md).

म्यूटेंट, और वे कहाँ हैं

म्यूटेशन टूल — Java के लिए PIT, JavaScript, C# और Scala के लिए Stryker, C और C++ के लिए Mull — आपके कोड में छोटे-छोटे बदलाव करता है और हर बदलाव के विरुद्ध टेस्ट चलाता है। जिस बदलाव पर किसी टेस्ट का ध्यान नहीं जाता, वह बचा हुआ म्यूटेंट है: कोड चला, पर किसी ने नहीं जाँचा कि उसने क्या किया। म्यूटेशन स्कोर बताता है कि कितने पकड़े गए; 0.2026.83 से एडिटर बताता है कि बाक़ी कहाँ हैं। ऐसे म्यूटेंट वाली लाइन के अंत में एक नोट होता है (⚑ 2 mutants survived), जहाँ रिपोर्ट बताती है कि कौन-सा टेक्स्ट बदला गया था वहाँ बदला हुआ टेक्स्ट रेखांकित होता है (Stryker और Mull यह बताते हैं), ओवरव्यू रूलर में एक पट्टी होती है, और होवर करने पर दिखता है कि क्या बदला गया, कितने टेस्ट ने उसे चलाया, और पकड़े गए म्यूटेंट के लिए, किस टेस्ट ने उन्हें पकड़ा।

Screenshot pending — add assets/img/mutant-hover.png (see SCREENSHOTS.md).

बच गया का अर्थ है कि टेस्ट ने बदला हुआ कोड चलाया और सभी पास हुए। अनटेस्टेड (रिपोर्ट का no coverage) का अर्थ है कि कोई भी टेस्ट उस कोड को चलाता ही नहीं, इसलिए किसी का ध्यान जा ही नहीं सकता था। पकड़े गए म्यूटेंट होवर में गिने जाते हैं और कभी चिह्नित नहीं होते, और जो म्यूटेंट कभी एक निष्पक्ष परीक्षा थे ही नहीं — जैसे वह जो कंपाइल ही नहीं होता — वे स्कोर से बाहर रहते हैं। एनोटेटेड सोर्स में ऐसी हर लाइन के नीचे एक पंक्ति और एक Next Mutant बटन (U) होता है, और HTML रिपोर्ट में एक Surviving Mutants सेक्शन होता है जो उस लाइन से लिंक करता है। कुछ भी चालू करने की ज़रूरत नहीं है, और जिस प्रोजेक्ट में म्यूटेशन रिपोर्ट नहीं है उसे इसमें से कुछ नहीं दिखता।

Screenshot pending — add assets/img/mutants.gif (see SCREENSHOTS.md).

क्या किसी टेस्ट का ध्यान जाता? कर्सर पर म्यूटेशन रन

पूरे प्रोजेक्ट का म्यूटेशन रन एक घंटा लेता है; एक फ़ंक्शन का रन एक मिनट। Run Mutation Tests Here वही एक मिनट चलाता है: फ़ोल्डर के म्यूटेशन रनर से वही फ़ंक्शन म्यूटेट करने को कहा जाता है जिसमें कर्सर है — या चुनी हुई लाइनें, या फ़ाइल — और रनर की रिपोर्ट स्क्रीन पर दिख रही कवरेज के साथ लोड होती है, जहाँ बचे हुए म्यूटेंट चिह्नित होते हैं। C# के लिए यह Stryker.NET है (dotnet tool install --global dotnet-stryker), जिसे कैरेक्टरों का स्पैन और वह टेस्ट प्रोजेक्ट बताया जाता है जो फ़ाइल के प्रोजेक्ट को संदर्भित करता है; JavaScript और TypeScript के लिए StrykerJS, जिसे लाइनें बताई जाती हैं; Java के लिए Maven के साथ PIT, जिसे क्लास बताई जाती है। म्यूटेशन रनर चाहे जैसे समाप्त हुआ हो, रन को इस कारण विफल नहीं माना जाता: अपने थ्रेशोल्ड से नीचे का स्कोर एक एग्ज़िट कोड है, और फिर भी एक रिपोर्ट है। जिस रनर ने कुछ नहीं लिखा, उसके बारे में यही बताया जाता है, और साथ में यह कि उसके लिए क्या इंस्टॉल होना चाहिए।

Screenshot pending — add assets/img/mutation-here.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-mutation-here.gif (see SCREENSHOTS.md).

VS Code का अपना Test Coverage व्यू

testCoverage.publish चालू होने पर (डिफ़ॉल्ट), हर लोड किया गया रन एडिटर के नेटिव Test Coverage व्यू में भी जाता है — Test Explorer का कवरेज पैनल, Explorer में उसके रखे प्रति-फ़ाइल प्रतिशत, और एडिटर का अपना Show Inline Coverage टॉगल — पंक्तियों, ब्रांच आर्मों और फ़ंक्शनों के रूप में, विवरण माँग पर लोड होते हुए, चाहे वे किसी भी ट्रेसफ़ाइल से आए हों और बिना किसी टेस्ट अडैप्टर के। Show in Test Coverage View सक्रिय रन को प्रकाशित करके पैनल खोलता है, सेटिंग चाहे जो कहे; स्टेटस-बार मेनू इसे quickActions.showTestCoverage के पीछे देता है। बंद होने पर Test Explorer में कोई Fucini Coverage प्रविष्टि दिखती ही नहीं। जब कोई ट्रेसफ़ाइल अपने टेस्ट के नाम देती है (lcov के TN: सेक्शन), तो हर टेस्ट Test Explorer में Fucini Coverage के नीचे दिखता है और व्यू किसी फ़ाइल की कवरेज को टेस्ट के अनुसार फ़िल्टर कर सकता है।

Screenshot pending — add assets/img/test-coverage-view.png (see SCREENSHOTS.md).

Problems पैनल में अनकवर्ड पंक्तियाँ

डिफ़ॉल्ट रूप से बंद क्योंकि यह स्वभाव से शोरभरा है, और केवल खुले दस्तावेज़ों के लिए ही — दो हज़ार फ़ाइलों का रन पैनल को भर नहीं सकता। problems.enabled से स्वतंत्र, जो प्रति फ़ाइल एक प्रविष्टि पर टिका रहता है:

{
  "fuciniCoverage.problems.perLine": "uncoveredAndPartial"
}

Screenshot pending — add assets/img/problems-panel.png (see SCREENSHOTS.md).

9. डिफ कवरेज

सजावट को git बेस रेफ के सापेक्ष बदली गई लाइनों तक सीमित करें — यह समीक्षा करने के लिए आदर्श कि किसी PR ने वास्तव में क्या कवर किया या नहीं किया:

{
  "fuciniCoverage.gitDiff.enabled": true,
  "fuciniCoverage.gitDiff.baseRef": "origin/main"
}

Screenshot pending — add assets/img/diff-coverage.png (see SCREENSHOTS.md).

नए कोड का गेट

threshold.newCode एक अलग गेट है, पूरे रन के गेटों के साथ: gitDiff.baseRef के मुक़ाबले बदली गई उन लाइनों में से जिन्हें मापा जा सकता है, वह न्यूनतम प्रतिशत जो चला होना चाहिए। कुल 62% वाला प्रोजेक्ट भी यह माँग कर सकता है कि जो आज लिखा जाए वह टेस्ट किया हुआ हो। यह हर लोड पर पूरे रन पर गिना जाता है, और रन स्क्रीन पर बना रहता है — gitDiff.enabled दूसरी चीज़ है: रन की जगह बदली हुई लाइनें। Check Coverage Thresholds और Problems की अनुपालन प्रविष्टियाँ इसकी विफलता एक अलग वाक्य में बताती हैं: New code 72.00% < 80% (18 of 25 line(s) changed against origin/main ran)। जिस बदलाव में मापने लायक कोई लाइन नहीं — कमेंट, एक README — वह कुछ भी विफल नहीं करता।

{
  "fuciniCoverage.threshold.newCode": 80,
  "fuciniCoverage.gitDiff.baseRef": "origin/main"
  }

Screenshot pending — add assets/img/new-code-gate.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-new-code-gate.png (see SCREENSHOTS.md).

नया कोड: टैग, लेखक और तारीख़ के हिसाब से

डिफ़ॉल्ट रूप से नया कोड वे लाइनें हैं जिन्हें वर्किंग ट्री gitDiff.baseRef के मुक़ाबले बदलता है — कोई ब्रांच, कोई कमिट, या कोई टैग: "v1.4.0" का मतलब है उस रिलीज़ के बाद का सब कुछ। दो सेटिंग्स वह पूछती हैं जो कोई रेफ़ नहीं पूछ सकता। gitDiff.author किसी लेखक के नाम का एक हिस्सा लेता है, और तब नया कोड वे लाइनें हैं जिन्हें git उस लेखक की बताता है; gitDiff.since एक तारीख़ लेता है, और तब नया कोड वे लाइनें हैं जो आख़िरी बार उस दिन या उसके बाद बदलीं, चाहे वे किसी भी ब्रांच से आई हों; दोनों साथ हों, तो उस दिन से उस लेखक की लाइनें। ये लाइनें git blame से पढ़ी जाती हैं, एक बार में एक फ़ाइल — जिसका असर बड़े रन में हर लोड पर महसूस होगा — और डिफ़ कवरेज तथा ऊपर के गेट के लिए डिफ़ की जगह लेती हैं। जो लाइन अभी कमिट नहीं हुई है, वह दोनों ही सूरतों में गिनी जाती है।

{
  "fuciniCoverage.gitDiff.author": "Ada",
  "fuciniCoverage.gitDiff.since": "2026-09-01"
  }

Screenshot pending — add assets/img/new-code-author.png (see SCREENSHOTS.md).

अप्रत्यक्ष बदलाव: जो बदला, हालाँकि किसी ने उसे छुआ नहीं

डिफ़ बताता है कि कौन-सी लाइनें बदलीं; दो रन बताते हैं कि कौन-सी लाइनें चलना बंद हुईं या चलना शुरू हुईं। देखने लायक लाइनें वे हैं जहाँ ये दोनों मेल नहीं खाते: वह कोड जिसे किसी ने संपादित नहीं किया और जो अब निष्पादित नहीं होता, क्योंकि कोई टेस्ट हटा दिया गया, कॉल के रास्ते में पहले आने वाली कोई ब्रांच अब जल्दी लौट जाती है, कोई फ़िक्स्चर बदल गया। डिफ़ की समीक्षा उन्हें देख ही नहीं सकती — परिभाषा से ही वे उसके बाहर हैं। Show Indirect Coverage Changes… उन्हें फ़ाइल दर फ़ाइल सूचीबद्ध करता है, जिस फ़ाइल की कवरेज सबसे ज़्यादा घटी वह सबसे पहले, और जिसे आप चुनें उसे उसकी पहली ऐसी लाइन पर खोलता है। जहाँ baseline.report किसी CI बेसलाइन का नाम देता है, वहाँ रन की तुलना उसी बेसलाइन से होती है — पुल रिक्वेस्ट भी उसी से परखी जाती है — और अन्यथा उससे ठीक पहले के रन से; जिन लाइनों को वर्किंग ट्री gitDiff.baseRef के मुक़ाबले बदलता है वे, और वह सब कुछ जो ऐसी जगह के नीचे है जहाँ वह बदलाव फ़ाइल की लाइनों को खिसका देता है, सूची से बाहर रखा जाता है।

Screenshot pending — add assets/img/indirect-changes.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-indirect-changes.png (see SCREENSHOTS.md).

10. समग्र स्कोर

छह संख्याओं की रिपोर्ट करने के बजाय, एक्सटेंशन उन्हें एक भारित हार्मोनिक माध्य (WHM) में समेटता है। प्रतिशत pᵢ और भार wᵢ वाले मेट्रिक्स के लिए:

WHM = ( Σ wᵢ ) / ( Σ wᵢ / pᵢ )

एक हार्मोनिक माध्य पर उसके सबसे छोटे पद का प्रभुत्व होता है, इसलिए एक कमजोर मेट्रिक को एक परफेक्ट मेट्रिक द्वारा छुपाया नहीं जा सकता — यह ठीक वही गुण है जो आप सुरक्षा गेट से चाहते हैं। डिफ़ॉल्ट भार:

उस मेट्रिक को स्कोर से हटाने के लिए किसी भी भार को 0 पर सेट करें। डेटा में मौजूद न होने वाले मेट्रिक्स (जैसे साधारण lcov रन में MC/DC) को बस छोड़ दिया जाता है।

ऑब्जेक्ट कोड और म्यूटेशन स्कोर का भार तब तक 0 रहता है जब तक आप कुछ और तय न करें (whmWeights.objectCode, whmWeights.mutation)। ऑब्जेक्ट-कोड कवरेज स्टेटमेंट कवरेज को अपने में समाहित करता है, इसलिए दोनों को भार देने से एक ही साक्ष्य दो बार गिना जाता है; म्यूटेशन स्कोर तो कवरेज है ही नहीं — कोई टेस्ट सूट हर लाइन चला सकता है और फिर भी कुछ न पकड़े। फिर भी दोनों का अपना कॉलम और अपना थ्रेशोल्ड होता है।

Screenshot pending — add assets/img/score-weights.svg (see SCREENSHOTS.md).

कंडीशन कवरेज

a && b एक डिसीज़न है — दो ब्रांच — और चार परिणामों वाली दो कंडीशन। कोई टेस्ट सूट दोनों ब्रांच से गुज़र सकता है और फिर भी b को कभी false नहीं देखता: ब्रांच कवरेज पूरा है और कंडीशन कवरेज चार में से तीन। यह स्तर DO-178C और ISO 26262 में ब्रांच कवरेज और MC/DC के बीच आता है, और 0.2026.83 से यह ब्रांच में समाहित होने के बजाय अपने आप में एक मेट्रिक है: स्टेटस-बार कार्ड में एक पंक्ति, Coverage व्यू, रिपोर्ट और एक्सपोर्ट में एक कॉलम, स्कोर में 3 का वेट (whmWeights.conditions) और एक गेट (threshold.conditions; standard प्रोफ़ाइल में गेट नहीं, safety में 100)।

Screenshot pending — add assets/img/branch-condition-mcdc.svg (see SCREENSHOTS.md).

इसे BullseyeCoverage के condition प्रोब, TRACE32 के cond एक्सपोर्ट और -fcondition-coverage के साथ बिल्ड किए गए GCC 14 से पढ़ा जाता है। जो रिपोर्ट कंडीशन और डिसीज़न में अंतर नहीं करती, उसमें ऐसी कोई पंक्ति, कॉलम या वेट नहीं होता। यदि आप Bullseye या TRACE32 का उपयोग करते हैं: पहले कंडीशन ब्रांच के रूप में गिनी जाती थीं, इसलिए इस रिलीज़ के साथ आपका ब्रांच प्रतिशत बदलता है, और नए वेट के साथ आपका समग्र स्कोर भी; स्कोर को पहले जैसा रखने के लिए whmWeights.conditions को 0 पर सेट करें।

GCC 14, लाइन दर लाइन। -fcondition-coverage के साथ gcov बताता है कि किस कंडीशन का कौन-सा परिणाम छूटा है — कंडीशन 1 कभी true नहीं हुई, कंडीशन 0 कभी किसी भी तरफ़ नहीं गई — और हर कंडीशन अपनी लाइन पर चिह्नित होती है और होवर में उसका नाम आता है, gcov के JSON से भी और उसकी टेक्स्ट लिस्टिंग से भी (condition outcomes covered 3/6)। यह मेट्रिक वहीं है जहाँ बाक़ी मेट्रिक हैं: threshold.conditions इस पर गेट लगाता है, और जहाँ रन में ऐसा कोई आँकड़ा नहीं होता वहाँ वह गेट परखा ही नहीं जाता, Copy Coverage Summary में एक Conditions कॉलम है, badge.metric conditions स्वीकार करता है, और सर्च बॉक्स conditions < 80 स्वीकार करता है। फ़ंक्शन के ब्रांच आँकड़े में उसकी कंडीशनों के परिणाम शामिल नहीं होते, जैसे फ़ाइल और रन के ब्रांच आँकड़ों में नहीं होते।

Screenshot pending — add assets/img/gcc-conditions.png (see SCREENSHOTS.md).

जटिलता और CRAP

कुछ रिपोर्ट में हर फ़ंक्शन की साइक्लोमैटिक जटिलता होती है: OpenCover (जो Coverlet लिखता है), JaCoCo, Clover और Cobertura। जहाँ ऐसा होता है, वहाँ एक्सटेंशन उस जटिलता और स्वयं मापे गए कवरेज से फ़ंक्शन के लिए एक CRAP स्कोर — Change Risk Anti-Patterns — की गणना करता है:

CRAP = complexity² × (1 − coverage)³ + complexity

एक सरल, पूरी तरह परीक्षित फ़ंक्शन का स्कोर उसकी अपनी जटिलता के बराबर होता है, उससे अधिक नहीं; एक जटिल, मुश्किल से परीक्षित फ़ंक्शन का स्कोर सैकड़ों में पहुँचता है। डेमो प्रोजेक्ट के C# नमूने में Price() की जटिलता 22 है और उसकी लगभग 37% लाइनें कवर हैं, जिससे स्कोर 142.2 बनता है, जबकि Shipping() की जटिलता 12 है और वह पूरी तरह कवर है, जिससे स्कोर 12 बनता है। प्रचलित सीमा 30 है: इस पर या इससे ऊपर का फ़ंक्शन HTML रिपोर्ट में Riskiest Methods के अंतर्गत सूचीबद्ध होता है, सबसे ख़राब सबसे पहले।

Screenshot pending — add assets/img/crap-curve.svg (see SCREENSHOTS.md).

जटिलता और स्कोर फ़ंक्शन के CodeLens पर और एनोटेटेड सोर्स में फ़ंक्शन के बगल में दिखते हैं। Max CRAP किसी फ़ाइल के किसी भी फ़ंक्शन का उच्चतम स्कोर है — सबसे ख़राब वाला, औसत नहीं — और यह Coverage व्यू, HTML रिपोर्ट और CSV तथा Markdown एक्सपोर्ट में एक कॉलम है। यह केवल जानकारी है: इसका कोई थ्रेशोल्ड नहीं है और समग्र स्कोर में कोई भार नहीं है। जिन रिपोर्ट में जटिलता नहीं होती (lcov, gcov, Istanbul, coverage.py) उनमें CRAP नहीं होता, और कोई खाली कॉलम भी नहीं।

0.2026.83 से यह C और C++ के लिए भी उपलब्ध है। llvm-cov कोई जटिलता रिपोर्ट नहीं करता, इसलिए इसे उस ब्रांच डेटा से गिना जाता है जो रिपोर्ट में पहले से मौजूद है: फ़ंक्शन की अपनी फ़ाइल में लिखी गई कंडीशन, और एक — यह McCabe की परिभाषा है, और वही जो .NET और Java के लिए सोर्स-स्तर के टूल गिनते हैं। जो कंडीशन किसी दूसरी फ़ाइल के मैक्रो से आई हैं — उदाहरण के लिए हर assert — वे नहीं गिनी जातीं।

Screenshot pending — add assets/img/riskiest-methods.png (see SCREENSHOTS.md).

Risk hotspots, और कौन सी फ़ाइलें दिखानी हैं

Coverage व्यू के ट्री के नीचे, Risk hotspots उन फ़ंक्शनों की सूची देता है जहाँ जटिल कोड कम कवरेज से मिलता है, सबसे खराब पहले, और हर एक अपनी फ़ाइल को उस फ़ंक्शन पर खोलता है। कोई फ़ंक्शन CRAP स्कोर से योग्य होता है — hotspots.crapThreshold, डिफ़ॉल्ट रूप से 30, वह आँकड़ा जो मेट्रिक के लेखकों ने प्रस्तावित किया — या अकेले साइक्लोमैटिक जटिलता से, hotspots.complexityThreshold, डिफ़ॉल्ट रूप से बंद; केवल जटिलता ले जाने वाली रिपोर्टों (OpenCover, Coverlet की Cobertura, JaCoCo, llvm-cov) में कोई होते हैं। Community गिनती और सबसे खराब स्कोर देखता है; क्रमबद्ध सूची Pro में है। सॉर्ट के बगल में एक दूसरा ड्रॉपडाउन बताता है कि ट्री कौन सी फ़ाइलें दिखाए — सभी, कमी वाली फ़ाइलें, बिना परखी फ़ाइलें, या पिछले रन के बाद बदली फ़ाइलें; फ़ोल्डर अपनी फ़ाइलों का अनुसरण करते हैं और अपने आँकड़े रखते हैं। दोनों Visual Studio में भी हैं, Coverage विंडो में।

Screenshot pending — add assets/img/vs-hotspots.png (see SCREENSHOTS.md).

नेमस्पेस, क्लास और मेथड

ऐसी .NET रिपोर्ट के लिए जो अपनी क्लासों के नाम बताती है — Cobertura और Coverlet की coverage.cobertura.xml, OpenCover — एक तीसरा ड्रॉपडाउन, Folders / Namespaces, उसी रन को नेमस्पेस, क्लास और मेथड के रूप में खींचता है: नेमस्पेस का आँकड़ा उसकी क्लासों का जोड़ है, क्लास का उसके मेथडों का, ठीक वैसे जैसे फ़ोल्डर का उसकी फ़ाइलों का, उसी सॉर्ट और उसी फ़िल्टर के साथ। मेथड की पंक्ति फ़ाइल को मेथड पर खोलती है; जो क्लास किसी नेमस्पेस में घोषित नहीं है वह (no namespace) के नीचे है। चुनाव coverageView.perspective में लिखा जाता है; जिस रन में क्लास के नाम नहीं हैं उसमें कोई ड्रॉपडाउन नहीं होता और वह अपने फ़ोल्डर दिखाता है। Visual Studio में Coverage विंडो में वही ड्रॉपडाउन है।

Screenshot pending — add assets/img/namespace-perspective.png (see SCREENSHOTS.md).

ट्री में खोजना

बटनों और ड्रॉपडाउन के नीचे एक खोज बॉक्स। एक शब्द उन पंक्तियों को रखता है जिनके नाम या पथ में वह है — टाइप किया गया हर शब्द वहाँ होना चाहिए; एक तुलना उन पंक्तियों को रखती है जिनका आँकड़ा उसे पास करता है — स्कोर पर < 80%, lines >= 90, branches = 0, functions != 100, mcdc < 50 — और invoice < 80 दोनों चाहता है। नेमस्पेस परिप्रेक्ष्य की मेथड पंक्तियाँ और risk hotspot फ़ाइलों के साथ खोजे जाते हैं, इसलिए फ़ंक्शन वहीं मिलता है जहाँ रन में वह है। ट्री आपके टाइप करते-करते पेज में ही फ़िल्टर होता है, बिना दोबारा बनाए; जिस फ़ोल्डर में मेल है वह उसके लिए खुलता है और बॉक्स खाली होने पर फिर बंद हो जाता है; Esc उसे साफ़ करता है। वही बॉक्स, वही व्याकरण, Visual Studio में।

Screenshot pending — add assets/img/tree-search.gif (see SCREENSHOTS.md).

ट्री एडिटर के साथ-साथ चलता है

जो फ़ाइल आप देख रहे हैं वह Coverage व्यू में हाइलाइट होती है, उसके ऊपर के फ़ोल्डर खुल जाते हैं और उसकी पंक्ति स्क्रॉल होकर सामने आ जाती है — जो फ़ाइल पहले से खुली है उसे अब ट्री में ढूँढ़ना नहीं पड़ता। बाक़ी समय ट्री अपनी स्क्रॉल स्थिति बनाए रखता है, और कुछ भी दोबारा ड्रॉ नहीं होता। डिफ़ॉल्ट रूप से चालू सेटिंग coverageView.followActiveEditor से इसे बंद किया जा सकता है, उन लोगों के लिए जो ट्री को वहीं छोड़ना पसंद करते हैं जहाँ उन्होंने उसे रखा था।

Screenshot pending — add assets/img/follow-editor.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-follow-editor.gif (see SCREENSHOTS.md).

11. अनुपालन गेटिंग

COMPLIANT / NON-COMPLIANT निर्णय (एनोटेटेड-सोर्स व्यू, HTML रिपोर्ट और दोनों स्टेटस-बार होवर में दिखाया गया) प्रति-मेट्रिक थ्रेशोल्ड और एक मोड द्वारा संचालित होता है:

Screenshot pending — add assets/img/statusbar.png (see SCREENSHOTS.md).

0 का थ्रेशोल्ड उस गेट को बंद कर देता है, और जो मेट्रिक रिपोर्ट में मौजूद नहीं है उसका मूल्यांकन कभी नहीं होता। जो थ्रेशोल्ड आपने सेट नहीं किया है उसका क्या अर्थ है, यह नीचे दी गई प्रोफ़ाइल तय करती है। मांग पर मूल्यांकन के लिए Fucini Coverage: Check Coverage Thresholds चलाएँ।

Screenshot pending — add assets/img/vs-error-list.png (see SCREENSHOTS.md).

थ्रेशोल्ड प्रोफ़ाइल

threshold.profile तय करता है कि जो थ्रेशोल्ड आपने सेट नहीं किया है उसका क्या अर्थ है। standard, जो 0.2026.82 से डिफ़ॉल्ट है, वह स्तर है जिसकी अपेक्षा किसी ऐसे सामान्य प्रोजेक्ट से की जा सकती है जो सुरक्षा से संबंधित नहीं है। safety में हर गेट 100 पर होता है — जो एक सेफ़्टी केस माँगता है, और ठीक वही जो 0.2026.81 तक शिप होता था।

जो थ्रेशोल्ड आपने स्वयं सेट किया है, वह दोनों में से किसी भी प्रोफ़ाइल पर भारी पड़ता है। उदाहरण में ब्रांच का गेट 90 पर और बाकी सब का 100 पर है; केवल कुछ मेट्रिक को 100 पर रखने के लिए standard पर बने रहें और उन्हें स्वयं सेट करें। सेटिंग्स के काम करने के तरीके से एक सावधानी निकलती है: शिप किए गए डिफ़ॉल्ट के बराबर मान को बिना किसी मान की स्थिति से अलग नहीं पहचाना जा सकता, इसलिए safety के अंतर्गत ठीक अपने मानक आँकड़े के रूप में लिखा गया थ्रेशोल्ड — मान लीजिए लाइनों के लिए 80 — तब भी 100 ही गिना जाता है।

{
  "fuciniCoverage.threshold.profile": "safety",
  "fuciniCoverage.threshold.branch": 90
}

Screenshot pending — add assets/img/threshold-profile.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/threshold-profiles.gif (see SCREENSHOTS.md).

यदि आप पुराने डिफ़ॉल्ट पर निर्भर थे, तो 0.2026.82 में अपडेट करने के बाद, जब तक आप safety नहीं चुनते, आपका मूल्यांकन अधिक नरमी से होता है। जो इंस्टॉलेशन पहले से चल रहा था उसे यह बात एक बार बताई जाती है, साथ में Keep 100% (safety) बटन होता है जो प्रोफ़ाइल को आपकी उपयोगकर्ता सेटिंग्स में लिख देता है; साझा प्रोजेक्ट के लिए इसे वर्कस्पेस सेटिंग्स में भी रखें, ताकि सभी का मूल्यांकन एक समान हो। Configure Coverage Compliance & Thresholds... में प्रोफ़ाइल थ्रेशोल्ड ग्रिड के ऊपर है, और इसका लाइव पूर्वावलोकन वास्तव में लागू गेट के आधार पर मूल्यांकन करता है। हर कार्ड और रिपोर्ट में, जिस मेट्रिक का गेट बंद है, वह अपना आँकड़ा सही या ग़लत के निशान के बजाय एक तटस्थ डैश के साथ दिखाता है।

Screenshot pending — add assets/img/statusbar-metrics.png (see SCREENSHOTS.md).

11a. ऑब्जेक्ट-कोड कवरेज

यहाँ हर दूसरी मेट्रिक स्रोत से मापी जाती है: एक टूल आपके कोड को इंस्ट्रुमेंट करता है, इंस्ट्रुमेंटेड बिल्ड चलता है, और काउंटर बताते हैं कि कौन-से स्टेटमेंट, ब्रांच या कंडीशन चले। ऑब्जेक्ट-कोड कवरेज कुछ और मापता है — बनी हुई बाइनरी का कितना हिस्सा वास्तव में चला, इंस्ट्रक्शन बाइट में गिना गया, स्रोत को इंस्ट्रुमेंट करने के बजाय इंस्ट्रक्शन स्ट्रीम देखकर। यह मायने रखता है क्योंकि कंपाइलर ऐसा कोड निकालता है जिसका हिसाब आपके स्रोत की किसी पंक्ति में नहीं है: ऐरे-बाउंड जाँच, switch जंप टेबल, रजिस्टर स्पिल, स्टैक प्रोब, और जिन कोर में निर्देश ही नहीं है वहाँ भाग या फ़्लोटिंग-पॉइंट के लिए रनटाइम हेल्पर रूटीन की कॉल। यह यहाँ की इकलौती मेट्रिक भी है जो क्या यह असेंबली को कवर करता है? का उत्तर देती है — हाथ से लिखी असेंबली कभी इंस्ट्रुमेंट नहीं होती, और स्रोत-आधारित टूल वहाँ तक पहुँचता ही नहीं। DO-178C कारण स्पष्ट कहता है: स्तर A पर, जहाँ कंपाइलर या लिंकर ऐसा कोड बनाता है जो सीधे स्रोत स्टेटमेंट तक ट्रेस नहीं होता, उद्देश्य 6.4.4.2b ठीक उसी उत्पन्न कोड के लिए अतिरिक्त सत्यापन माँगता है।

यह स्टेटमेंट कवरेज को समाहित करता है — निष्पादित हर निर्देश किसी न किसी स्टेटमेंट से आया है, इसलिए 100% ऑब्जेक्ट-कोड कवरेज का अर्थ 100% स्टेटमेंट कवरेज है। उलटा सही नहीं है, और यही विषमता इसे मापने का पूरा कारण है। इससे दो बातें निकलती हैं। संयुक्त स्कोर में इसका कोई भार नहीं है, क्योंकि एक ही निष्पादन के दो मापों का औसत लेना एक ही साक्ष्य को दो बार गिनना है; इसके बजाय इसे fuciniCoverage.threshold.objectCode से गेट किया जाता है — भार नहीं, बल्कि एक अपेक्षा, और मानक इसे इसी रूप में माँगता है। और अंतर ही असली परिणाम है: 100% लाइन कवरेज और 100% से कम ऑब्जेक्ट-कोड कवरेज वाला रन ठीक वही कंपाइलर-जनित कोड ढूँढ़ लाया है जिसका हिसाब आपके स्रोत में नहीं है, इसलिए कंप्लायंस कार्ड इसे «94%» में दबाने के बजाय कहता है 312 बाइट कभी नहीं चले, जबकि लाइन कवरेज 100% है। इसका उलटा — पूरी बाइनरी चली हुई बताई जाए जबकि उसका स्रोत नहीं — कम स्कोर नहीं, विरोधाभास है: लगभग हमेशा मर्ज के एक ओर पुरानी ट्रेसफ़ाइल, या मॉड्यूल नाम जो फ़ाइल पथों से कभी मेल ही नहीं खाए। इसे एक फ़ाइंडिंग के रूप में बताया जाता है।

ऑब्जेक्ट-कोड कवरेज के लिए ज़रूरी है कि बाइनरी वहाँ चले जहाँ उसके निर्देश देखे जा सकें। तीन रास्ते हैं और उनकी लागत में ज़मीन-आसमान का अंतर है। ऑब्जेक्ट-कोड कवरेज केवल तीसरा देता है; पहले दो इसलिए यहाँ हैं क्योंकि वे एक मिलती-जुलती समस्या हल करते हैं — अक्सर वही जिसे वास्तव में हल करना सार्थक है।

1. टारगेट पर चलने वाला इंस्ट्रुमेंटेड बिल्ड। GCC क्रॉस-कंपाइलर -fprofile-arcs -ftest-coverage स्वीकार करते हैं, तो जो इंस्ट्रुमेंटेशन वर्कस्टेशन पर चलता है वही टारगेट पर भी चलता है — बस इतना कि बेयर-मेटल सिस्टम में .gcda काउंटर लिखने के लिए फ़ाइल सिस्टम नहीं होता, और अक्सर उन्हें लिखने के लिए exit() भी नहीं। काउंटर वैसे भी RAM में रहते हैं, इसलिए हल यह है कि उस मेमोरी को डंप करें और फ़ाइलें टारगेट के बाहर दोबारा बनाएँ; NASA JPL का embedded-gcov (Apache-2.0) ठीक यही करता है — बिना फ़ाइल सिस्टम, बिना ऑपरेटिंग सिस्टम, बिना मानक C लाइब्रेरी के। इससे मिलता है आपके क्रॉस-कंपाइलर द्वारा, आपके इंस्ट्रक्शन सेट के लिए, आपके हार्डवेयर पर बने बिल्ड का स्टेटमेंट, ब्रांच और फ़ंक्शन कवरेज — ऑब्जेक्ट-कोड कवरेज नहीं, और मापी गई बाइनरी इंस्ट्रुमेंटेड है, यानी आप जो भेजते हैं उससे बड़ी और धीमी। परिणाम को LCOV, gcovr JSON, gcov JSON के रूप में लोड करें, या GCC 9 से पुराने टूलचेन पर सादा-टेक्स्ट .gcov लिस्टिंग के रूप में।
2. इंस्ट्रक्शन-सेट सिम्युलेटर। असली टारगेट बाइनरी को सिम्युलेटर में चलाइए और निष्पादित पतों से कवरेज निकालिए: न हार्डवेयर, न इंस्ट्रुमेंटेशन, न प्रोब — और चूँकि यह निर्देश देखता है, यह असली ऑब्जेक्ट-कोड कवरेज दे सकता है। सीमा है सटीकता: सिम्युलेटर कोर का मॉडल अच्छा बनाता है और पेरिफ़ेरल का कमज़ोर, इसलिए पूरे सिस्टम के नतीजों पर तब तक संदेह रखिए जब तक वह आपके सिलिकॉन का बारीक मॉडल न बनाता हो।
3. ऑन-चिप ट्रेस और डिबगर। प्रमाणन-स्तर का रास्ता, और सचमुच अ-हस्तक्षेपी एकमात्र रास्ता: कोर की ट्रेस यूनिट इंस्ट्रक्शन स्ट्रीम डिबगर को बताती है, जो उसे कवरेज में बदल देता है। कुछ भी इंस्ट्रुमेंट नहीं होता, कोड का आकार नहीं बदलता और टाइमिंग अछूती रहती है — और यही बात नतीजे को उस बाइनरी का प्रमाण बनाती है जो आप वास्तव में भेजते हैं। बजट बनाने से पहले सिलिकॉन जाँचिए: कई माइक्रोकंट्रोलर परिवारों में पूरा ट्रेस केवल बड़े ट्रेस बफ़र और तेज़ ट्रेस पोर्ट वाले एमुलेशन या डेवलपमेंट वैरिएंट पर ही मिलता है, जबकि प्रोडक्शन पुर्ज़े घटी हुई ट्रेस यूनिट देते हैं, जिनके लिए विक्रेता का विकल्प एक सॉफ़्टवेयर ट्रेस है जो कोड को इंस्ट्रुमेंट करता है और CPU समय खाता है — यानी वही गुण मिटा देता है जिसके लिए यह रास्ता चुना गया था।

कई एम्बेडेड प्रोजेक्ट डेवलपमेंट मशीन के लिए वही स्रोत कंपाइल करके और वहीं यूनिट टेस्ट चलाकर कवरेज मापते हैं। यह तेज़ है, हार्डवेयर की ज़रूरत नहीं पड़ती, और अधिकांश टीमों के लिए यही सही डिफ़ॉल्ट है — लेकिन यह साफ़ समझ लेना ज़रूरी है कि वह साक्ष्य असल में क्या बताता है: एक अलग कंपाइलर, एक अलग ऑप्टिमाइज़र, एक अलग इंस्ट्रक्शन सेट, और भेजी जाने वाली बाइनरी से अलग बाइनरी। अधिकांश सॉफ़्टवेयर के लिए यह एक स्वीकार्य और अच्छी तरह समझा गया समझौता है। IEC 61508, ISO 26262 या DO-178C के विरुद्ध आँके जाने वाले काम के लिए यह वही मानक «होस्ट बनाम टारगेट» आपत्ति है, और ऊपर दिए रास्ते उसके मानक जवाब हैं — पहला इसे स्रोत कवरेज के लिए बंद करता है, तीसरा ऑब्जेक्ट कोड के लिए।

आज ऑब्जेक्ट कोड के लिए पढ़ा जाने वाला एक्सपोर्ट Lauterbach TRACE32 का COVerage.EXPORT.ListModule है, जिसमें metric="object" हो; इसे किसी भी अन्य ट्रेसफ़ाइल की तरह लोड कीजिए। यह मेट्रिक केवल पेड लाइसेंस पर और मूल्यांकन अवधि के दौरान स्कोर और गेट की जाती है। Community इंस्टॉल इसे स्कोर नहीं करता — लेकिन जब कोई ट्रेसफ़ाइल इसे साथ लाती है तो बताया ज़रूर जाता है, क्योंकि एक ऐसा कंप्लायंस फ़ैसला जो फ़ाइल में मौजूद सबसे मज़बूत साक्ष्य को चुपचाप छोड़ दे, उस फ़ैसले से बुरा होगा जो बताता है कि उसने क्या छोड़ा।

12. गैर-कोड लाइनों को बाहर रखना

excludeComments चालू होने पर (डिफ़ॉल्ट), स्टेटमेंट जो पूरी तरह से केवल-टिप्पणी या खाली लाइनों पर पड़ते हैं, कुल से बाहर रखे जाते हैं — यह एक ज्ञात llvm-cov/gcov विचित्रता को भी बेअसर करता है जहां एक भटकी हुई हिट काउंट किसी टिप्पणी पर उतरती है। मानक मार्कर भी सम्मानित हैं:

x = risky();          // LCOV_EXCL_LINE
// LCOV_EXCL_START
debug_only_block();
// LCOV_EXCL_STOP

C, C++, Objective-C, CUDA और C# में प्रीप्रोसेसर निर्देश भी कोड नहीं गिने जाते: # से शुरू होने वाली पंक्ति — #define, #include, #if — और वे पंक्तियाँ जिन तक अंत का बैकस्लैश उसे जारी रखता है। gcov किसी मैक्रो के हर उपयोग को उस पंक्ति के खाते में डालता है जहाँ वह परिभाषित है, इसलिए जिस हेडर की एकमात्र रिपोर्ट की गई पंक्ति #define CHANNEL_COUNT (33U) थी, वह 100% कवर्ड पढ़ा जाता था क्योंकि .c फ़ाइल का एक लूप उस तक चला, और जिस हेडर के स्थिरांक का कोई उपयोग नहीं करता था वह 0% पढ़ा जाता था। ऐसे हेडर में अब मापने को कुछ नहीं है और वह सूचीबद्ध नहीं होता।

बाहर रखी गई लाइनों को फिर भी गिनने के लिए excluded.includeInTotals को true पर सेट करें।

किसी फ़ाइल या फ़ोल्डर को बाहर रखना, ट्री से

Coverage व्यू में किसी फ़ाइल या फ़ोल्डर पर राइट-क्लिक करें और Exclude from Coverage चुनें — यह पंक्ति की पथ क्रियाओं में भी है — या खुली फ़ाइल पर Exclude This File from Coverage चलाएँ: फ़ाइल का वर्कस्पेस-सापेक्ष पथ, या फ़ोल्डर का /**, फ़ोल्डर की सेटिंग्स में fuciniCoverage.ignore में चला जाता है, एक बार, और रीलोड उसे हर टोटल और हर पेज से हटा देता है; पैटर्न वहीं रहता है ताकि उसे फिर से निकाला जा सके। Visual Studio में पंक्ति के मेनू और Tools → Coverage Studio में वही दो हैं, जो वही सेटिंग उसी फ़ाइल में लिखते हैं।

Screenshot pending — add assets/img/exclude-from-tree.gif (see SCREENSHOTS.md).

एट्रिब्यूट और नेमस्पेस, .NET के लिए

दो सेटिंग्स सोर्स से वह पढ़ती हैं जो रिपोर्ट नहीं बता सकती। ignore.attributes — डिफ़ॉल्ट रूप से ExcludeFromCodeCoverage — अपने बताए किसी एट्रिब्यूट के नीचे की क्लास, मेथड या प्रॉपर्टी को बाहर रखता है, जैसे LCOV_EXCL_START/STOP रखते, चाहे रिपोर्ट किसी भी टूल ने लिखी हो: Coverlet इस एट्रिब्यूट को मानता है, OpenCover, dotCover और कन्वर्ट की गई lcov नहीं मानते, और अब वे सब सहमत हैं। नाम Attribute प्रत्यय के साथ या बिना, नेमस्पेस के साथ या बिना; GeneratedCode, Obsolete या अपने खुद के जोड़ें। ignore.namespaces हर उस फ़ाइल को बाहर रखता है जिसकी नेमस्पेस घोषणा किसी उपसर्ग से मेल खाती है, * वाइल्डकार्ड के रूप में — Acme.Generated, Acme.*.Migrations, *Tests — और Output पैन उन फ़ाइलों के नाम बताता है जो उसने हटाईं। दोनों उसी पास में पढ़े जाते हैं जो कमेंट मार्कर पढ़ता है, दोनों संस्करणों में।

{
  "fuciniCoverage.ignore.attributes": ["ExcludeFromCodeCoverage", "GeneratedCode"],
  "fuciniCoverage.ignore.namespaces": ["Acme.Generated", "*.Migrations"]
}

एडिटर से बाहर रखना

लाइनें चुनें और लाइट बल्ब, एडिटर के कॉन्टेक्स्ट मेनू या Command Palette से Exclude Selection from Coverage लें — Visual Studio में लाइट बल्ब (Ctrl+.), कोड विंडो का राइट-क्लिक मेनू, Tools → Coverage Studio या Ctrl+Shift+U, X — और बहिष्करण वहीं लिखा जाता है जहाँ कोड है: C#, VB या F# की क्लास, मेथड या प्रॉपर्टी के ऊपर [ExcludeFromCodeCoverage], फ़ाइल में System.Diagnostics.CodeAnalysis पहले से इम्पोर्ट हो तो छोटे नाम से और न हो तो पूरी तरह क्वालिफ़ाइड, ताकि कोई using जोड़ना न पड़े; कोड की एक लाइन के अंत में LCOV_EXCL_LINE; कई लाइनों के चारों ओर, पहली लाइन के इंडेंटेशन पर, LCOV_EXCL_START और LCOV_EXCL_STOP — भाषा के अपने कमेंट चिह्न के साथ, //, #, ', -- या ;। एक अनडू स्टेप। जिस लाइन को Problems की प्रविष्टियाँ बिना-कवर बताती हैं, उस पर भी लाइट बल्ब इसे देता है। जो लाइन पहले से चिह्नित है, या जिस सदस्य पर पहले से एट्रिब्यूट है, वह जैसी है वैसी छोड़ दी जाती है।

Screenshot pending — add assets/img/exclude-selection.gif (see SCREENSHOTS.md).

केवल ब्रांच, और gcovr के मार्कर

एक रक्षात्मक else, एक default: जिस तक कोई मान नहीं पहुँचता, वह आर्म जो कंपाइलर किसी एक्सेप्शन के लिए जोड़ता है: लाइन चलती है और उसे गिना जाना चाहिए, बस उसकी ब्रांच नहीं ली जा सकती। LCOV_EXCL_BR_LINE और LCOV_EXCL_BR_START … LCOV_EXCL_BR_STOP अपनी लाइनों की ब्रांचों को गिनती से बाहर कर देते हैं और लाइनों को गिनती में रहने देते हैं। LCOV_EXCL_EXCEPTION_BR_LINE और उसका रीजन इससे भी कम हटाते हैं — केवल वे आर्म जो किसी एक्सेप्शन पर लिए जाते हैं, जहाँ रिपोर्ट बताती है कि वे कौन-से हैं, जैसा gcov का JSON बताता है। हर मार्कर gcovr के उपसर्गों के साथ भी पढ़ा जाता है: GCOVR_EXCL_LINE, GCOVR_EXCL_START, GCOVR_EXCL_BR_LINE, GCOV_EXCL_STOP और बाक़ी सबका वही अर्थ है जो LCOV_EXCL_ वाले मार्करों का है, इसलिए gcovr के लिए लिखा गया सोर्स यहाँ भी वैसे ही पढ़ा जाता है, रिपोर्ट चाहे किसी भी टूल ने बनाई हो। जो नहीं पढ़ा जाता: GCOVR_EXCL_FUNCTION — उस लाइन पर ऐसा कुछ नहीं है जो बताए कि फ़ंक्शन कहाँ समाप्त होता है।

if (handle == NULL) return E_FAIL;   // LCOV_EXCL_BR_LINE: the allocator never fails on target
  // LCOV_EXCL_BR_START generated state table
  switch (state) { /* … */ }
  // LCOV_EXCL_BR_STOP

Screenshot pending — add assets/img/branch-markers.png (see SCREENSHOTS.md).

कारण बताना: औचित्य वाले बहिष्करण

कोड को गिनती से बाहर करना एक दावा है — "इसे टेस्ट नहीं किया जा सकता", "यह डेवलपर की सहायता के लिए है" — और DO-178C, ISO 26262 या IEC 61508 के तहत जो दावा उस संख्या को बदलता है जिस पर कोई प्रमाणपत्र टिका है, उसे लिखित और समीक्षा योग्य होना चाहिए। इसलिए बहिष्करण अपना कारण बता सकता है, वहीं जहाँ वह लिखा है: LCOV_EXCL_LINE या LCOV_EXCL_START के बाद का टेक्स्ट, या [ExcludeFromCodeCoverage] की Justification।

abort();                 // LCOV_EXCL_LINE: defensive, unreachable by construction
  // LCOV_EXCL_START debug dump, never built for the target

  [ExcludeFromCodeCoverage(Justification = "a developer aid")]
  public static void DebugDump(decimal amount) { /* … */ }

कारण हर लोड पर पढ़े जाते हैं और लॉग उन्हें गिनता है। Export Coverage Report… यह सूची लिखता है — exclusions and their justifications, Markdown या CSV के रूप में: फ़ाइल, लाइनें, बहिष्करण कैसे लिखा गया, और औचित्य या none given। जिस फ़ाइल में मापने लायक कुछ नहीं बचा, वह भी उस सूची में रहती है। exclusions.requireReason चालू होने पर, जो बहिष्करण कोई कारण नहीं देता वह एक निष्कर्ष है: उसकी लाइन पर Problems में एक चेतावनी, और Check Coverage Thresholds की विफलता। तब Exclude Selection from Coverage पहले कारण पूछता है और उसे मार्कर के साथ या एट्रिब्यूट की Justification के रूप में लिखता है; यह सवाल रद्द कर देने या खाली छोड़ देने पर कुछ भी बाहर नहीं रखा जाता।

Screenshot pending — add assets/img/justified-exclusions.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-justified-exclusions.png (see SCREENSHOTS.md).

12a. क्या यह कवरेज अब भी इसी फ़ाइल का वर्णन करती है?

12b. बिना मापी बनाम अनकवर्ड

{
  "fuciniCoverage.unmeasured.mode": "list",
  "fuciniCoverage.threshold.unmeasuredFiles": 0
}

C में हेडर फ़ाइलें जानी-पहचानी झूठी सकारात्मक हैं: उनके पास रन का एक्सटेंशन परिवार है और कोई ट्रेसफ़ाइल कभी किसी का नाम नहीं लेगी, क्योंकि अकेले वह किसी चीज़ में कंपाइल नहीं होती। इसलिए fuciniCoverage.unmeasured.exclude डिफ़ॉल्ट रूप से **/*.h, **/*.hpp, **/*.hh, **/*.inl और **/*.d.ts को बाहर रखता है, fuciniCoverage.ignore वाले ही ग्लोब सिंटैक्स में; यहाँ न बनने वाला प्लेटफ़ॉर्म पोर्ट, या जनरेट किए गए स्टब जोड़ें, और वे सूची, गिनती और स्टेटस-बार स्थिति से निकल जाते हैं। जिस फ़ाइल का नाम ignore लेता है, उसे भी कभी बिना मापी नहीं कहा जाता — उसे बाहर रखना ही तो मक़सद था। threshold.unmeasuredFiles का डिफ़ॉल्ट -1 है, जो जाँच नहीं करता; 0 उसी क्षण विफल होता है जब रन के प्रकार की कोई भी फ़ाइल किसी टेस्ट द्वारा कभी लोड नहीं की गई हो, और यह केवल तभी लागू होता है जब unmeasured.mode list या count हो।

13. HTML रिपोर्ट

• Generate Full HTML Report — प्रति-डायरेक्टरी, स्व-रेंडर्ड, बहु-पृष्ठ रिपोर्ट। आउटपुट htmlReport.outputDir में जाता है, या अनसेट होने पर एक्सटेंशन के ग्लोबल स्टोरेज में।
• Open Annotated Source — एकल फ़ाइल के लिए एनोटेटेड व्यू। बिल्ट-इन रेंडरर के बजाय उन पृष्ठों का उपयोग करने के लिए externalHtmlReport.dir को पूर्व-निर्मित llvm-cov show --format=html डायरेक्टरी पर इंगित करें।
• Export Fucini JSON — आपके अपने टूलिंग के लिए पूर्ण सामान्यीकृत मॉडल।
• Export Coverage Report... — रन को CSV (प्रति फ़ाइल या प्रति फ़ंक्शन), Markdown सारांश, LCOV ट्रेसफ़ाइल, Cobertura XML, SARIF, या अपने README के लिए स्वतः पूर्ण SVG बैज के रूप में। Covered Files दृश्य में Generate Full HTML Report के बगल वाले बटन से भी पहुँचा जा सकता है। CSV को छोड़कर सब कुछ हानिकर है — MC/DC, रीजन और इंस्टैंशिएशन के लिए LCOV, Cobertura या SARIF में जगह नहीं है — इसलिए हर मीट्रिक ले जाने वाले फ़ॉर्मैट Fucini JSON और CSV ही रहते हैं।
• Copy Uncovered Lines — हर अंतराल का एक Markdown सारांश, PR में पेस्ट करने के लिए तैयार।

Screenshot pending — add assets/img/vs-annotated-source.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-directory-summary.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-file-summary.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-coverage-gaps.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/report-mcdc-detail.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/export-picker.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/annotated-source.png (see SCREENSHOTS.md).

एनोटेटेड सोर्स बनाम सामान्य सोर्स

Open Annotated Source उस फ़ाइल के लिए सक्रिय टैब को उसी कॉलम में एक रंग-कोडित कवरेज वेबव्यू से बदल देता है; Open Annotated Source to the Side वही काम करता है लेकिन स्प्लिट में, ताकि सोर्स और एनोटेटेड व्यू एक-दूसरे के बगल में रहें। इसके बजाय उसी जगह आगे-पीछे स्विच करने के लिए — छोटी स्क्रीन पर उपयोगी जहाँ स्प्लिट हर पैनल को बहुत संकरा बना देता है — Toggle Annotated Source का उपयोग करें: यह सक्रिय टैब को दोनों के बीच बदलता है, यह याद रखते हुए कि आप वर्तमान में कौन-सा देख रहे हैं। एनोटेटेड व्यू के अंदर से, Show Source सीधे उस फ़ाइल के सामान्य एडिटर पर वापस ले जाता है।

आप वास्तव में कौन-सा HTML देखते हैं यह externalHtmlReport.dir पर निर्भर करता है: जब यह सेट हो और सक्रिय फ़ाइल से मेल खाता एक पेज पहले से वहाँ मौजूद हो (llvm-cov प्रति-फ़ाइल पेजों को <repo-नाम>/<सापेक्ष-पथ>.html के रूप में व्यवस्थित करता है, इसलिए रिपोर्ट के अपने repo-नाम फ़ोल्डर को कभी कॉन्फ़िगर करने की आवश्यकता नहीं होती), तो बिल्ट-इन रेंडरर के बजाय टूलचेन द्वारा जनरेट किया गया वही पेज दिखाया जाता है — इसके लोकल लिंक/स्टाइलशीट को वेबव्यू के अंदर काम करने के लिए फिर से लिखा जाता है, और इसमें ऐसे विवरण होते हैं जिन्हें बिल्ट-इन व्यू पुनः प्रस्तुत नहीं करता (MC/DC विस्तार व्यू, क्षेत्र हाइलाइटिंग, डायरेक्टरी रोलअप)। उस फ़ाइल के लिए कोई मेल खाता पेज नहीं है, या सेटिंग खाली छोड़ दी गई है? तब बिल्ट-इन रेंडरर का उपयोग किया जाता है। एक्सटेंशन केवल इस डायरेक्टरी को पढ़ता है — यह इसमें कभी नहीं लिखता।

README के लिए कवरेज बैज

Generate Coverage Badge सक्रिय रन के लिए shields-शैली का SVG वर्कस्पेस में लिखता है — badge.outputPath, डिफ़ॉल्ट coverage-badge.svg, वर्कस्पेस फ़ोल्डर के सापेक्ष या निरपेक्ष, हर दूसरी पथ सेटिंग वाले ही वेरिएबल के साथ — और उसे खोलने की पेशकश करता है। यह आपकी रिपॉज़िटरी में एक सादी फ़ाइल है, इसलिए README उसे बिना किसी सेवा के, बिना shields.io के चक्कर के एम्बेड करता है, और यह एयर-गैप्ड रिपॉज़िटरी में भी काम करता है:

![coverage](coverage-badge.svg)

badge.metric चुनता है कि बैज क्या दिखाए: lines (लेबल coverage), branches, mcdc या weighted, वही समग्र स्कोर जो स्टेटस बार दिखाता है, लेबल score। चुनी गई मेट्रिक का डेटा न रखने वाले रन को लाल 0% के बजाय धूसर n/a मिलता है। रंग आपके अपने colorScale.* स्तरों का अनुसरण करता है: lowThreshold से नीचे lowColor, highThreshold तक midColor, वहाँ से highColor। badge.autoUpdate चालू होने पर बैज हर सफल लोड के बाद चुपचाप फिर लिखा जाता है, और आउटपुट चैनल हर लेखन को [FUCINI_BADGE] के रूप में दर्ज करता है — डिफ़ॉल्ट रूप से बंद क्योंकि यह हर लोड पर वर्कस्पेस में लिखता है। SVG को कोड के साथ कमिट करें और रिपॉज़िटरी पेज की तस्वीर एडिटर की संख्या का अनुसरण करती है।

{
  "fuciniCoverage.badge.outputPath": "docs/coverage-badge.svg",
  "fuciniCoverage.badge.metric": "weighted",
  "fuciniCoverage.badge.autoUpdate": true
}

14. इतिहास और रुझान

रन को स्थानीय रूप से बनाए रखने के लिए history.enabled सक्षम करें (उनमें से history.retention रखते हुए)। फिर आपको स्टेटस बार में एक रुझान तीर (▲/▼), Coverage व्यू में रुझान चार्ट, और दो तुलना कमांड मिलते हैं: Compare with Last Run और Compare Two History Runs, जिनमें से प्रत्येक प्रति-फ़ाइल रिग्रेशन/सुधार डिफ बनाता है।

Screenshot pending — add assets/img/history-compare.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/since-last-run.png (see SCREENSHOTS.md).

रुझान चार्ट

Coverage व्यू के टूलबार के नीचे, दो या अधिक सहेजे गए रनों के साथ, इतिहास की लाइन कवरेज एक रेखा के रूप में, सबसे पुराने से सबसे नए तक, नवीनतम तीस: प्रति रन एक बिंदु जो होवर पर अपनी तारीख़ और आँकड़ा बताता है, और उसके बगल में आख़िरी आँकड़ा, पहले के बाद की दिशा बताने वाले तीर के साथ। ऊर्ध्वाधर पैमाना रनों की अपनी सीमा है, इसलिए 92–94% पर चल रही टीम को 100 के नीचे एक सपाट रेखा नहीं, बल्कि हलचल दिखती है। दोनों संस्करण इसे एक ही इतिहास से खींचते हैं।

Screenshot pending — add assets/img/trend-chart.png (see SCREENSHOTS.md).

कवरेज सेशन

एक टेस्ट रन शायद ही कभी वह सब कवर करता है जिसे किसी बदलाव ने छुआ: यूनिट टेस्ट यहाँ चले, इंटीग्रेशन सूट वहाँ, कवरेज चालू करके UI की सैर कहीं और। Start Coverage Session उसके बाद के लोड को एक जोड़ में बदल देता है — हर रन पिछले में लाइन दर लाइन यूनियन के रूप में जुड़ता है, जो लाइन उनमें से किसी ने भी चलाई वह कवर्ड है और गिनतियाँ जुड़ती हैं — ताकि गटर, ट्री और स्कोर वह दिखाएँ जहाँ तक वे सब मिलकर पहुँचे। स्क्रीन पर मौजूद रन, अगर कोई है, सेशन का पहला है। ट्री के ऊपर एक पट्टी बताती है कि कब से कितने रन, और सेशन समाप्त करती है; End Coverage Session भी यही करता है, और अगला लोड फिर से अकेला खड़ा होता है। Visual Studio में Tools → Coverage Studio के नीचे एक ही प्रविष्टि सेशन शुरू करती है और, चेक की हुई, उसे समाप्त करती है।

Screenshot pending — add assets/img/coverage-session.gif (see SCREENSHOTS.md).

CI बेसलाइन: main के मुक़ाबले मैं कहाँ हूँ?

Compare with Last Run बताता है कि आपके पिछले बदलाव ने क्या किया; पुल रिक्वेस्ट से पहले सवाल यह है कि आप main के मुक़ाबले कहाँ खड़े हैं, और जवाब बिल्ड सर्वर पर है। baseline.report उस रिपोर्ट का नाम देता है जो main ब्रांच का बिल्ड प्रकाशित करता है, और हर लोड उसके सामने रखा जाता है: स्टेटस बार के कार्ड पर एक पंक्ति का अंतर होता है — vs CI baseline: 84.20% → 85.10% (+0.90%), 3 file(s) moved — और Compare with CI Baseline उन फ़ाइलों को सूचीबद्ध करता है जो बदलीं, फ़ाइल दर फ़ाइल, उन्हीं शब्दों में जिनमें Compare with Last Run। Visual Studio में यह कमांड Tools → Coverage Studio के नीचे है और आपके कहने पर रिपोर्ट लाता या पढ़ता है। .vscode/settings.json में उसका नाम देने के तीन तरीक़े:

{
  "fuciniCoverage.baseline.report": "https://gitlab.example.com/api/v4/projects/42/jobs/artifacts/main/raw/coverage/lcov.info?job=test",
  "fuciniCoverage.remote.headers": ["PRIVATE-TOKEN: ${env:GITLAB_TOKEN}"]
}

रीडर जिस भी फ़ॉर्मैट को जानता है, वह चलेगा। जो पथ CI ने अपने चेकआउट के सापेक्ष लिखा — src/Billing/Invoice.cs, जैसा Coverlet रनर पर लिखता है — वह डिफ़ से पहले इस फ़ोल्डर के नीचे रखा जाता है, ताकि वह उस फ़ाइल से मिले जिसे स्थानीय रन ने रिज़ॉल्व किया; दूसरी मशीन का पूर्ण पथ किसी से नहीं मिलता, इसलिए पाइपलाइन से सापेक्ष पथ लिखवाएँ। जो बेसलाइन लाई या पढ़ी नहीं जा सकती वह Output पैन में एक पंक्ति है, कभी भी विफल लोड नहीं।

Screenshot pending — add assets/img/ci-baseline.gif (see SCREENSHOTS.md).

आर्टिफ़ैक्ट एक zip होता है, और वह भी पढ़ा जाता है। GitHub और GitLab आर्टिफ़ैक्ट को आर्काइव के रूप में देते हैं, उसमें चाहे जो रखा गया हो। आर्काइव के भीतर की रिपोर्ट का नाम # के बाद दें: वह फ़ाइल अपने पथ से या पथ के अंतिम हिस्से से खोजी जाती है; # के बिना वह आर्काइव की एकमात्र फ़ाइल होती है, या उसकी एकमात्र फ़ाइल जो रिपोर्ट जैसी दिखती है, और जहाँ ऐसी कई फ़ाइलें हों वहाँ Output पैन उनके नाम बताता है। यही बात आपके डाउनलोड किए हुए zip (ci/artifact.zip#lcov.info) पर और, VS Code में, coverageFile.paths के URL पर लागू होती है। टोकन उसी सर्वर को जाता है जिसके लिए वह सेट किया गया था, और उससे आगे नहीं: जिस स्टोरेज में आर्काइव रखा है उसकी ओर का रीडायरेक्ट बिना टोकन के फ़ॉलो किया जाता है।

{
  "fuciniCoverage.baseline.report": "https://api.github.com/repos/acme/app/actions/artifacts/1234567/zip#coverage/lcov.info",
  "fuciniCoverage.remote.headers": ["Authorization: Bearer ${env:GITHUB_TOKEN}"]
  }

14a. AI एजेंटों के लिए: स्क्रीन पर दिख रही कवरेज

टेस्ट लिखने वाला एजेंट उन्हें चला सकता है और एक प्रतिशत पढ़ सकता है। जो वह अपने आप नहीं कर सकता, वह है यह पूछना कि एडिटर क्या जानता है: इस फ़ंक्शन की कौन-सी लाइनें कभी नहीं चलीं, किस ब्रांच का कौन-सा पक्ष छूटा, किसी लाइन को कौन-से टेस्ट चलाते हैं, जो डिफ़ उसने अभी लिखा वह कवर्ड है या नहीं। छह टूल ठीक इन्हीं सवालों के जवाब देते हैं, ऐसे शब्दों में जिन पर एजेंट अमल कर सके, उसी रन से जो लोड है — वही बहिष्करण, वही रीमैपिंग, वही आँकड़े जो स्क्रीन पर हैं। इस तरह, जिस एजेंट को किसी फ़ंक्शन की कवरेज की कमियाँ भरने को कहा गया है और जो समीक्षक गटर देख रहा है, वे दोनों उन्हीं लाइनों की बात कर रहे होते हैं।

VS Code के अपने एजेंट को ये टूल के रूप में मिलते हैं, बिना कुछ सेट अप किए। बाक़ी हर एजेंट — MCP, यानी Model Context Protocol, बोलने वाला कोई भी क्लाइंट — इन तक उस सर्वर के ज़रिये पहुँचता है जिसे एडिटर mcp.enabled चालू होने पर चलाता है, VS Code और Visual Studio दोनों में एक समान। Copy MCP Server Configuration क्लाइंट की प्रविष्टि क्लिपबोर्ड पर रखता है, उसी रूप में जिसमें VS Code और Visual Studio उसे mcp.json में पढ़ते हैं; जो क्लाइंट बाहरी कुंजी को mcpServers नाम देता है, वह वही प्रविष्टि उस नाम के नीचे लेता है।

Screenshot pending — add assets/img/mcp-config.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/vs-mcp-config.png (see SCREENSHOTS.md).

{
  "servers": {
    "fucini-coverage": {
      "type": "http",
      "url": "http://127.0.0.1:39217/mcp",
      "headers": { "Authorization": "Bearer …" }
    }
  }
  }

• जब तक आप इसे चालू न करें यह बंद रहता है, और यह केवल 127.0.0.1 पर सुनता है: इस मशीन के बाहर से कुछ भी इस तक नहीं पहुँचता।
• हर कॉल के साथ आपका टोकन होना चाहिए, जो एक बार बनाया जाता है और आपके लिए सँभालकर रखा जाता है; उसके बिना जवाब 401 है। कॉपी किए गए कॉन्फ़िगरेशन में टोकन होता है: उसे रिपॉज़िटरी से बाहर रखें।
• जो कॉल किसी वेब पेज ने भेजी है — यह उसके Origin में लिखा होता है — वह अस्वीकार कर दी जाती है, चाहे वह अपने साथ कुछ भी लाए।
• यह उसी रन को पढ़ता है जो लोड है, और कुछ नहीं लिखता। टेस्ट रन का कमांड केवल बताया जाता है, रन शुरू नहीं किया जाता: एजेंट वह कमांड अपने टर्मिनल में चलाता है।

पोर्ट mcp.port है, और जब तक सेट न किया जाए तब तक 39217। जहाँ वह पोर्ट पहले से इस्तेमाल में हो — दूसरी विंडो, इसके साथ चल रहा दूसरा संस्करण — वहाँ अगला खाली पोर्ट इस्तेमाल होता है, और कॉपी किया गया कॉन्फ़िगरेशन उसी पोर्ट का नाम देता है जो काम करता है। Output पैन बताता है कि सर्वर कहाँ सुन रहा है ([FUCINI_MCP]) और वह क्यों नहीं सुन सका ([FUCINI_MCP_001])। जो किसी प्लान में शामिल नहीं है — टेस्ट के नाम, MC/DC का विवरण — उसे टूल केवल गिनते हैं, उसका ब्योरा नहीं देते, जैसा होवर भी करता है।

15. कमांड संदर्भ

Screenshot pending — add assets/img/statusbar-and-toolbar.gif (see SCREENSHOTS.md).

Screenshot pending — add assets/img/statusbar-menu.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/worst-functions.png (see SCREENSHOTS.md).

16. सेटिंग्स संदर्भ

पूर्ण, वर्गीकृत सेटिंग्स तालिका — हर विकल्प उसके डिफ़ॉल्ट के साथ — विशेषताएँ और सेटिंग्स पेज पर मौजूद है। सभी की का उपसर्ग fuciniCoverage. है।

ध्यान देने योग्य: fuciniCoverage.language, VS Code की डिस्प्ले भाषा से स्वतंत्र रूप से, इस एक्सटेंशन के अपने रनटाइम UI (स्टेटस बार, सूचनाएं, टूलटिप, वेबव्यू) को किसी विशेष भाषा से जोड़ देता है — यह डिफ़ॉल्ट रूप से auto है और सभी 18 समर्थित भाषाओं के लिए बंडल के साथ आता है। यह कमांड पैलेट प्रविष्टियों या सेटिंग्स UI लेबल को नहीं बदलता, जिन्हें VS Code अपनी खुद की डिस्प्ले भाषा से हल करता है।

17. त्रुटि कोड

डायग्नोस्टिक्स Fucini Coverage आउटपुट चैनल (View → Output → Fucini Coverage) में जाते हैं, प्रत्येक का एक स्थिर FUCINI_* कोड होता है।

18. गोपनीयता

टेलीमेट्री window-स्कोप वाली telemetry.enabled सेटिंग से नियंत्रित होती है। यह डिफ़ॉल्ट रूप से बंद है। दैनिक सारांश और हटाने की सूचना के लिए VS Code की वैश्विक telemetry.telemetryLevel का टेलीमेट्री की अनुमति देना भी ज़रूरी है; इंस्टॉल संकेत और कुछ छोटी घटनाएँ हर हाल में भेजी जाती हैं, और वैसे ही परीक्षण अवधि या मुफ़्त Community स्तर पर चल रहे इंस्टॉल की उपयोग बही प्रविष्टि भी। Community पर, Unlock Full Features इस टेलीमेट्री के बदले MC/DC सहित हर Pro सुविधा देता है, 30 दिनों के लिए, प्रति मशीन एक बार — इसे फिर से बंद करें और मानक Community सेट लागू हो जाता है; सशुल्क लाइसेंस दोनों ही स्थितियों में प्रभावित नहीं होता। क्या भेजा जाता है, यह गोपनीयता नीति में देखें।

दो बातें जानने योग्य हैं, क्योंकि उन पर आप कुछ कर सकते हैं। पहली है आपका उपयोग बही ID: ट्रायल पर और Community पर एक्सटेंशन इसे Show License / Activation के अंतर्गत और What Community Includes के अंत में दिखाता है, जहाँ उस पंक्ति को चुनने पर वह कॉपी हो जाती है और नीति खुल जाती है। बही आपकी मशीन को केवल एक हैश से जानती है और किसी और चीज़ से नहीं, इसलिए यह पूछने का कि उसमें आपके बारे में क्या दर्ज है, उसे मिटवाने का, या उस पर आपत्ति करने का एकमात्र रास्ता यही ID है — इसे बताइए और हम आपकी पंक्ति ढूँढ़ सकते हैं; इसके बिना नहीं ढूँढ़ सकते। दूसरी है इंस्टॉल रिकॉर्ड: एक पंक्ति, जो किसी इंस्टॉल के पहली बार रिपोर्ट करने पर लिखी जाती है और 90 दिन बाद मिटाने के बजाय रखी जाती है; इसमें इंस्टॉल पहचानकर्ता, दिन, उसके पते से पहचाना गया स्थान, संस्करण और ऑपरेटिंग सिस्टम होते हैं — पता स्वयं नहीं, और आपके कोड के बारे में कुछ भी नहीं। इसी से हम बता पाते हैं कि इन वर्षों में कुल कितने इंस्टॉल हुए। दोनों का पूरा विवरण गोपनीयता नीति में है, और कहने पर दोनों मिटा दिए जाते हैं।

19. मूल्यांकन और सक्रियण

Fucini Coverage Studio एक मूल्यांकन प्री-रिलीज़ के रूप में वितरित किया जाता है। पहली बार चलाने पर आपसे इसका मूल्यांकन करने की सहमति माँगी जाती है और ट्रायल शुरू हो जाता है — हर सुविधा 14-दिन के ट्रायल के दौरान उपलब्ध रहती है, जिसे उस इंस्टॉल पर पहली बार उपयोग से गिना जाता है। ऐसी कोई नियत तिथि नहीं है जिसके बाद कुछ बंद हो जाए।

संस्करण 2.2026.2 से नए इंस्टॉल का ट्रायल तभी शुरू होता है जब एक्सटेंशन एक बार लाइसेंस सर्वर तक पहुँच जाता है; तब तक वह Community टियर पर चलता है और यह बताता है। डेवलपमेंट कंटेनर या Codespace में कोई ट्रायल शुरू नहीं होता — वहाँ सब्सक्रिप्शन कोड, कुंजी या 7-दिन का पास पूरा सेट अनलॉक करता है।

ट्रायल समाप्त होने पर कुछ भी बंद नहीं होता: एक्सटेंशन मुफ़्त Community स्तर पर आ जाता है। पूरा सेट वापस पाने के लिए सक्रिय करें — सक्रियण लाइसेंस सर्वर से जुड़ता है और लौटाई गई कुंजी अपने आप लागू कर देता है, न कोई ईमेल, न हाथ से कोई कुंजी लिखना:

Screenshot pending — add assets/img/licence-dialog.png (see SCREENSHOTS.md).

1. Fucini Coverage: Show License / Activation चलाएँ (ट्रायल या कुंजी समाप्त होने के बाद स्टेटस बार से भी पहुँचा जा सकता है) और Request License… पर क्लिक करें (यदि आपने पहले सक्रिय किया है तो Request Renewed Key…)।
2. अनुरोध की पुष्टि करें। कुंजी अपने आप जारी होती है, और किसी पिछले अनुरोध के आपके संपर्क विवरण फिर से पूछे जाने के बजाय पुनः उपयोग किए जाते हैं।
3. बस इतना ही। सक्रियण कुंजी बनती है और अपने आप fuciniCoverage.license.key में लिख दी जाती है। स्टेटस बार पल भर में ट्रायल से सक्रिय लाइसेंस पर बदल जाता है।

मैनुअल रास्ता एक तस्वीर में: लाइसेंस पैनल खोलिए, Enter Key चुनिए, ईमेल से मिली कुंजी चिपकाइए — और बैनर “Activated” हो जाता है।

Screenshot pending — add assets/img/activate-key.gif (see SCREENSHOTS.md).

{ "fuciniCoverage.license.key": "FCK1.…पूरी कुंजी यहाँ चिपकाएँ…" }

मुफ़्त Community टियर: साप्ताहिक कोटा

Community कवरेज दिखाना कभी बंद नहीं करता। गटर, ओवरव्यू रूलर, होवर, CodeLens, Coverage व्यू, वॉच मोड, डिफ़ कवरेज और इतिहास बिल्कुल नहीं गिने जाते, और कमांड से ट्रेसफ़ाइल लोड करने की सीमा केवल 25 प्रतिदिन है। जो मापा जाता है वह है आउटपुट: HTML रिपोर्ट खोलना, एक्सपोर्ट करना, दो रन की तुलना करना, थ्रेशोल्ड जाँचना और एनोटेटेड सोर्स को उसी जगह देखना — प्रत्येक सप्ताह में पाँच बार।

सप्ताह आपका अपना है, कैलेंडर का नहीं: यह पहले उपयोग से शुरू होता है और सात दिन बाद समाप्त होता है। जब कोई कोटा समाप्त हो जाता है, तो संदेश उस क्रिया का नाम और वह दिन बताता है जब कोटा वापस आएगा, और उस एक संदेश के बाद केवल स्टेटस बार इसका उल्लेख करता है। Fucini Coverage: What Community Includes हर कोटा को सूचीबद्ध करता है — कितना उपयोग हो चुका है और कब रीसेट होगा — इससे पहले कि आप किसी सीमा तक पहुँचें।

Screenshot pending — add assets/img/weekly-allowance.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/community-limit-prompt.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/community-includes-weekly.png (see SCREENSHOTS.md).

तीन विवरण सशुल्क प्लान के हैं, जबकि उनके निष्कर्ष मुफ़्त रहते हैं: Community हर उस पंक्ति को चिह्नित करता है जिसमें जीवित बचे म्यूटेंट हैं और उनकी संख्या बताता है, पर यह नहीं कि प्रत्येक म्यूटेंट ने क्या बदला; यह बताता है कि किसी पंक्ति को कितने टेस्ट ने चलाया, पर उनके नाम नहीं; और यह किसी रन का Max CRAP दिखाता है, पर क्रमबद्ध Riskiest Methods सूची नहीं।

Screenshot pending — add assets/img/mutant-hover-community.png (see SCREENSHOTS.md).

यदि साप्ताहिक कोटा आने के समय (0.2026.83) आप पहले से Community का उपयोग कर रहे थे, तो आपकी पिछली सीमाएँ 30 दिन तक बनी रहती हैं; आपको यह एक बार, तारीख के साथ बताया जाता है। काउंटर आपकी मशीन पर रखे जाते हैं — VS Code के अपने स्टोरेज में और ~/.fucini-coverage/ में, इसलिए नई VS Code प्रोफ़ाइल उसी सप्ताह को जारी रखती है — और कभी कहीं नहीं भेजे जाते।

7-दिन का पास

सब्सक्रिप्शन के लिए अभी तैयार नहीं हैं? 7-दिन का पास एक सप्ताह के लिए Pro की हर सुविधा देता है, एक बार के भुगतान पर: कुछ भी नवीनीकृत नहीं होता और रद्द करने के लिए कुछ नहीं है। इसे मूल्य पृष्ठ पर खरीदें (Community की सीमा पर आने वाले संदेश में इसके लिए एक बटन होता है), और एक्टिवेशन कोड ईमेल से आ जाता है।

Screenshot pending — add assets/img/pricing-week-pass.png (see SCREENSHOTS.md).

1. Fucini Coverage: Enter Subscription Code चलाएँ — यह Community संस्करण और Pro, दोनों में मौजूद है।
2. Pro चुनें और ईमेल में मिला FCB1-… कोड पेस्ट करें।
3. बस इतना ही। कुंजी आपके लिए जारी और लागू कर दी जाती है, और ऑफ़लाइन काम करती है। सप्ताह भुगतान के समय से गिना जाता है, इसलिए ख़रीदते ही एक्टिवेट करें। अवधि पूरी होने पर एक्सटेंशन अपने आप Community पर लौट आता है और कवरेज दिखाता रहता है।

Screenshot pending — add assets/img/pass-step-plan.png (see SCREENSHOTS.md).

Screenshot pending — add assets/img/pass-step-code.png (see SCREENSHOTS.md).

नए कंप्यूटर पर जाना, और सीटों का प्रबंधन

कुंजी एक मशीन से बँधी होती है, इसलिए नए कंप्यूटर को नई कुंजी चाहिए — और आपकी सदस्यता उतनी ही मशीनों का भुगतान करती है जितनी वह बताती है। पुरानी को स्वयं मुक्त करें: अपनी सदस्यता प्रबंधित करें में साइन इन करें, जो सीट अब उपयोग में नहीं है उसे ढूँढ़ें, Free up चुनें, और फिर उसी कोड से नई मशीन सक्रिय करें। Pro खरीदने पर आपको कोई पासवर्ड नहीं भेजा जाता — आपका खाता मौजूद है, बस उसमें अभी पासवर्ड नहीं है, इसलिए पहली बार उसी पते से पासवर्ड सेट या रीसेट करें जिससे आपने सदस्यता ली थी।

Business और Enterprise में आप उसी पृष्ठ से हर सहकर्मी को ईमेल द्वारा आमंत्रित करते हैं। हर किसी को केवल उसका अपना सक्रियण कोड मिलता है, और उपयोग करते ही उसका पता उसकी सीट के सामने दिखने लगता है — कोई छोड़कर जाए तो आप देख सकते हैं कि कौन-सी सीट उसकी थी और उसे अगले व्यक्ति के लिए मुक्त कर सकते हैं। आमंत्रण भेजते ही एक सीट रोक लेता है और अप्रयुक्त रहने पर 14 दिन में समाप्त हो जाता है; उसे वापस लेकर सीट तुरंत खाली की जा सकती है।

प्री-रिलीज़ बिल्ड परखना

नया काम Marketplace तक पहुँचने से पहले fucini.software पर आता है, और आप उसे पाने के लिए कह सकते हैं। Coverage दृश्य खोलें, लाइसेंस पैनल फैलाएँ और प्री-रिलीज़ बिल्ड परखें… दबाएँ — या fuciniCoverage.update.preRelease सेट करें। उसके बाद एक्सटेंशन सामान्य फ़ीड के साथ-साथ यहाँ की अलग प्री-रिलीज़ फ़ीड भी जाँचता है और दोनों में से जो नया हो वही प्रस्तुत करता है।

Screenshot pending — add assets/img/licence-prerelease.png (see SCREENSHOTS.md).

प्री-रिलीज़ परखे गए हैं, पर यही वे बिल्ड हैं जिन पर हमें सबसे कम भरोसा है — आप स्वेच्छा से वह खोजने आ रहे होंगे जो हमसे छूट गया। शामिल होने पर हमें पता चलता है कि यह इंस्टॉल उस चैनल में है, जिससे हम जान पाते हैं कि कितने लोग परख रहे हैं और आपको बता पाते हैं कि क्या बदला; छोड़ने पर अगली स्थिर रिलीज़ आपको सामान्य रास्ते पर लौटा देती है। प्री-रिलीज़ हमेशा उपलब्ध नहीं होती, और जब कोई न हो तब शामिल होने में कुछ नहीं जाता: एक्सटेंशन को खाली फ़ीड मिलती है, वह उसके बारे में कुछ नहीं कहता, और जब तक कोई प्रकाशित न हो तब तक स्थिर रिलीज़ प्रस्तुत करता रहता है।

Screenshot pending — add assets/img/licence-prerelease-joined.png (see SCREENSHOTS.md).

20. संपर्क और लाइसेंस

प्रश्न, बग रिपोर्ट, या वैकल्पिक लाइसेंसिंग शर्तें — संपर्क पेज देखें या info@fucini.consulting पर ईमेल करें। रिलीज़ नोट्स में एट्रिब्यूशन शर्त के साथ MIT के तहत लाइसेंस प्राप्त; Notice भी देखें।

21. कमांड-लाइन पर

रीडर एडिटर के बिना भी चलता है: npm install -g fucini-coverage, मुफ़्त, Windows, Linux, WSL और macOS पर। fucini-coverage check coverage/lcov.info --lines 80 वह गेट है जिस पर पाइपलाइन विफल होती है; summary, export, report, badge और compare वही करते हैं जो एडिटरों में इन नामों की कमांड करती हैं, और mcp ऊपर वाले अनुभाग के छह टूल एक सर्वर पर किसी एजेंट को परोसता है। यह fucini-coverage.json पढ़ता है, वही सेटिंग्स फ़ाइल जो Visual Studio संस्करण पढ़ता है, इसलिए थ्रेशोल्ड एक बार ही तय होते हैं। fucini-coverage help <command> हर एक को समझाता है; पूरा पेज npm पर fucini-coverage है।

Screenshot pending — add assets/img/cli-demo.gif (see SCREENSHOTS.md).