[[["わかりやすい","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 UTC。"],[],[],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."]]
