[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-25 (世界標準時間)。"],[],[],null,["\u003cbr /\u003e\n\nCloud Firestore and Realtime Database both rely on powerful, concise rules languages\nspecifically created to govern information security and access control. However,\nas rules get longer and more complex, you might need some help debugging errors\nin their behavior.\n\nThe Firebase Emulators include the ability to generate rule coverage reports, so you\ncan see see exactly what each subexpression evaluated to when you reproduce\nan error. The reports also provide information about how frequently each test\ncase used a rule, like traditional \"line coverage\" techniques.\n\nGenerate a report\n\nAfter running a suite of tests, you can access test\ncoverage reports that show how each of your security rules was evaluated.\n\nTo get the reports, query an exposed endpoint on the emulator while\nit's running. For a browser-friendly version, use the following URL: \n\nCloud Firestore \n\n```scdoc\nhttp://localhost:8080/emulator/v1/projects/\u003cdatabase_name\u003e:ruleCoverage.html\n \n```\n\nRealtime Database \n\n```scdoc\nhttp://localhost:9000/.inspect/coverage?ns=\u003cdatabase_name\u003e\n \n```\n\nThis breaks your rules into expressions and subexpressions that you can\nmouseover for more information, including number of evaluations and values\nreturned. For the raw JSON version of this data, include the following URL\nin your query: \n\nCloud Firestore \n\n```scdoc\nhttp://localhost:8080/emulator/v1/projects/\u003cdatabase_name\u003e:ruleCoverage\n \n```\n\nRealtime Database \n\n```scdoc\nhttp://localhost:9000/.inspect/coverage.json?ns=\u003cdatabase_name\u003e\n \n```\n\nDebugging example rules\n\nTo easily generate a test report, use the emulator quickstarts available on\nGitHub for [Cloud Firestore](https://github.com/firebase/quickstart-testing/) and [Realtime Database](https://github.com/firebase/quickstart-testing/).\nThese quickstarts guide you through properly installing\nand initializing the emulators, then generating sample tests from an example\nset of rules.\n\nConsider an example app using Cloud Firestore that counts how many times users\nclick a button. The app employs the following rules: \n\nCloud Firestore \n\n```css+lasso\n service cloud.firestore {\n match /databases/{database}/documents {\n match /counters/{counter} {\n allow read;\n allow write: if request.resource.data.value == resource.data.value +1;\n }\n }\n }\n \n```\n\nTo debug the errors in the rules shown above, use the following sample\nJavaScript test: \n\n const counter0 = db.collection(\"counters\").doc(\"0\");\n await firebase.assertSucceeds(counter0.set({value: 0}));\n\nThe emulator generates a report available at the URL noted above: \n\n```scdoc\nhttp://localhost:8080/emulator/v1/projects/\u003cdatabase_name\u003e:ruleCoverage.html\n```\n\nThe report shows the following undefined and null-value errors:\n\nThe problem with this specific example is that the rules don't differentiate\nbetween creating the document and updating the document. Consequently, the\nwrite isn't allowed if the document doesn't exist, and the document can't be\ncreated because it doesn't exist. Differentiating the \"write\" into two\nmore specific operations --- \"create\" and \"update\" --- solves the problem. \n\nCloud Firestore \n\n```css+lasso\n service cloud.firestore {\n match /databases/{database}/documents {\n match /counters/{counter} {\n allow read;\n allow create: if request.resource.data.value == 0;\n allow update: if request.resource.data.value == resource.data.value +1;\n }\n }\n }\n \n```\n\nThe generated report shows how frequently each rule was used and what was\nreturned."]]
