rules_registry.json

{
  "version": "1.3.1",
  "total_rules": 147,
  "generated_at": "2026-08-24T14:48:00Z",
  "priority_counts": {
    "P0_BLOCKER": 7,
    "P1_HIGH": 17,
    "P2_MEDIUM": 116,
    "P3_INFO": 7
  },
  "rules": [
    {
      "id": "2008-04-tott-avoiding-flakey-tests",
      "title": "TotT: Avoiding Flakey Tests",
      "source_file": "best_practices/2008-04-tott-avoiding-flakey-tests.md",
      "source_url": "https://testing.googleblog.com/2008/04/tott-avoiding-flakey-tests.html",
      "published_date": "2008-04-17",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P0_BLOCKER",
      "summary": "Isolate tests from external environments, shared mutable states, and unmanaged background workers.",
      "rationale": "Flaky tests destroy developer trust in CI pipelines, leading to ignored build breakages and production outages.",
      "enforcing_prompt": "CRITICAL: Eliminate all sources of test flakiness. Guarantee that tests are completely isolated, create unique temporary file directories, and clean up spawned background routines.",
      "dos": [
        "Use hermetic in-memory state or unique temporary test directories (`t.TempDir()`)",
        "Ensure all spawned goroutines/threads terminate before test completion"
      ],
      "donts": [
        "Share global variables or static mutable state across test functions",
        "Rely on unmanaged system environment variables"
      ],
      "linter_rule_id": "go:avoid-sleep-in-test"
    },
    {
      "id": "2008-04-tott-time-is-random",
      "title": "TotT: Time is Random",
      "source_file": "best_practices/2008-04-tott-time-is-random.md",
      "source_url": "https://testing.googleblog.com/2008/04/tott-time-is-random.html",
      "published_date": "2008-04-03",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P0_BLOCKER",
      "summary": "Treat time and clocks as dynamic inputs; never assume real time stands still between consecutive statements.",
      "rationale": "Reading `time.Now()` directly inside business logic makes unit test assertions brittle across leap seconds and CI pauses.",
      "enforcing_prompt": "CRITICAL: Inject clock interfaces or pass explicit `time.Time` values into domain functions. In Go 1.24+, use `testing/synctest` to step through time deterministically.",
      "dos": [
        "Inject a mockable `Clock` interface or frozen timestamp into time-sensitive methods",
        "Use `synctest` to test timers and timeouts deterministically"
      ],
      "donts": [
        "Call `time.Now()` or `System.currentTimeMillis()` directly inside business calculation logic",
        "Write assertions comparing real-time elapsed durations"
      ],
      "linter_rule_id": "go:avoid-sleep-in-test"
    },
    {
      "id": "2008-08-tott-sleeping-synchronization",
      "title": "TotT: Sleeping != Synchronization",
      "source_file": "best_practices/2008-08-tott-sleeping-synchronization.md",
      "source_url": "https://testing.googleblog.com/2008/08/tott-sleeping-synchronization.html",
      "published_date": "2008-08-21",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P0_BLOCKER",
      "summary": "Never use real-time sleep for test synchronization; use explicit event notification, channels, or virtual time.",
      "rationale": "Hardcoded sleeps make test suites slow and flaky on CI runners due to CPU throttling or scheduling jitter.",
      "enforcing_prompt": "CRITICAL: Under no circumstances should you call `time.Sleep()` or `Thread.sleep()` to wait for asynchronous workers in tests. Wrap async tests in Go 1.24 `testing/synctest.Run` or synchronize with channels and condition polling.",
      "dos": [
        "Use Go 1.24 `testing/synctest.Run` for zero-wall-clock virtual time advancements",
        "Use notification channels (`chan struct{}`) with timeout bounds for async coordination"
      ],
      "donts": [
        "Add arbitrary `time.Sleep(500 * time.Millisecond)` hoping background tasks finish",
        "Rely on wall-clock timing for deterministic assertions"
      ],
      "linter_rule_id": "go:avoid-sleep-in-test"
    },
    {
      "id": "2017-12-testing-on-toilet-only-verify-state",
      "title": "Testing on the Toilet: Only Verify State-Changing Method Calls",
      "source_file": "best_practices/2017-12-testing-on-toilet-only-verify-state.md",
      "source_url": "https://testing.googleblog.com/2017/12/testing-on-toilet-only-verify-state.html",
      "published_date": "2017-12-11",
      "language_scope": "universal",
      "category_id": "test_doubles",
      "priority": "P0_BLOCKER",
      "summary": "When using test doubles, verify only state-changing method calls (mutations), never read-only query calls.",
      "rationale": "Verifying getter or finder calls ties tests to internal implementation details, breaking tests during harmless refactorings.",
      "enforcing_prompt": "CRITICAL: When using mocks, ONLY verify invocations on state-changing methods (e.g. `Save()`, `ChargePayment()`, `SendNotification()`). NEVER assert call counts on read-only queries (e.g. `GetUser()`, `FindByID()`).",
      "dos": [
        "Assert expectations on methods that produce external side effects or state mutations",
        "Stub return values for query methods without verifying invocation count"
      ],
      "donts": [
        "Add `.Times(1)` or `verify()` on getters and read-only helper functions",
        "Assert intermediate data-fetching query sequences"
      ],
      "linter_rule_id": "go:mock-query-verification"
    },
    {
      "id": "2021-03-test-flakiness-one-of-main-challenges",
      "title": "Test Flakiness - One of the main challenges of automated testing (Part II)",
      "source_file": "best_practices/2021-03-test-flakiness-one-of-main-challenges.md",
      "source_url": "https://testing.googleblog.com/2021/03/test-flakiness-one-of-main-challenges.html",
      "published_date": "2021-03-24",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P0_BLOCKER",
      "summary": "Isolate tests from external environments, shared mutable states, and unmanaged background workers.",
      "rationale": "Flaky tests destroy developer trust in CI pipelines, leading to ignored build breakages and production outages.",
      "enforcing_prompt": "CRITICAL: Eliminate all sources of test flakiness. Guarantee that tests are completely isolated, create unique temporary file directories, and clean up spawned background routines.",
      "dos": [
        "Use hermetic in-memory state or unique temporary test directories (`t.TempDir()`)",
        "Ensure all spawned goroutines/threads terminate before test completion"
      ],
      "donts": [
        "Share global variables or static mutable state across test functions",
        "Rely on unmanaged system environment variables"
      ],
      "linter_rule_id": "go:avoid-sleep-in-test"
    },
    {
      "id": "2024-02-increase-test-fidelity-by-avoiding-mocks",
      "title": "Increase Test Fidelity By Avoiding Mocks",
      "source_file": "best_practices/2024-02-increase-test-fidelity-by-avoiding-mocks.md",
      "source_url": "https://testing.googleblog.com/2024/02/increase-test-fidelity-by-avoiding-mocks.html",
      "published_date": "2024-02-27",
      "language_scope": "universal",
      "category_id": "test_doubles",
      "priority": "P0_BLOCKER",
      "summary": "Prefer real implementations or high-fidelity in-memory fakes over interaction mocks whenever possible.",
      "rationale": "Interaction mocks test how code works rather than what it accomplishes, creating brittle test suites.",
      "enforcing_prompt": "CRITICAL: Default to real objects or high-fidelity in-memory fakes (e.g. `FakeUserRepository`, `FakeBlobStore`). Restrict interaction mocks strictly to external third-party I/O boundaries.",
      "dos": [
        "Use real objects when execution is fast and deterministic",
        "Maintain reusable, contract-compliant in-memory fakes for infrastructure layers"
      ],
      "donts": [
        "Mock domain entities, value objects, or lightweight utility structs",
        "Construct complex nested mock expectation trees for internal business code"
      ]
    },
    {
      "id": "2026-04-one-map-key-one-lookup",
      "title": "One Map Key, One Lookup",
      "source_file": "best_practices/2026-04-one-map-key-one-lookup.md",
      "source_url": "https://testing.googleblog.com/2026/04/one-map-key-one-lookup.html",
      "published_date": "2026-04-29",
      "language_scope": "universal",
      "category_id": "functions_and_data",
      "priority": "P0_BLOCKER",
      "summary": "Never perform duplicate map lookups for existence checking and value retrieval; look up once and reuse the value.",
      "rationale": "Double indexing pays key hashing and tree/bucket traversal costs twice, wasting CPU cycles and introducing race window bugs.",
      "enforcing_prompt": "CRITICAL: Look up map keys exactly once. In Go, always use the 2-value comma-ok idiom `if val, ok := m[k]; ok { use(val) }`. Never write `if _, ok := m[k]; ok { ... m[k] ... }`.",
      "dos": [
        "Bind the retrieved value in the if-init statement (`if val, ok := m[k]; ok`)",
        "Reuse the bound variable throughout the block"
      ],
      "donts": [
        "Check existence with `_, ok := m[k]` and immediately index `m[k]` again",
        "Perform multiple map index lookups with the same key in a tight loop"
      ],
      "linter_rule_id": "go:one-map-lookup"
    },
    {
      "id": "2008-07-breaking-law-of-demeter-is-like-looking",
      "title": "Breaking the Law of Demeter is Like Looking for a Needle in the Haystack",
      "source_file": "best_practices/2008-07-breaking-law-of-demeter-is-like-looking.md",
      "source_url": "https://testing.googleblog.com/2008/07/breaking-law-of-demeter-is-like-looking.html",
      "published_date": "2008-07-21",
      "language_scope": "universal",
      "category_id": "design_principles",
      "priority": "P1_HIGH",
      "summary": "Adhere to the Law of Demeter; do not chain through internal object graphs to reach distant collaborators.",
      "rationale": "Train-wreck call chains couple the caller to the internal object layout of every intermediary class.",
      "enforcing_prompt": "MANDATORY: Speak only to immediate collaborators. Never navigate deep object structures (`a.GetB().GetC().DoSomething()`). Ask the immediate owner to perform the action or provide the direct data.",
      "dos": [
        "Delegate domain operations to immediate collaborator objects",
        "Provide high-level convenience methods on container structs"
      ],
      "donts": [
        "Write deep call/field navigation chains (depth \u003e= 5)",
        "Expose internal nested dependencies through getters"
      ],
      "linter_rule_id": "go:law-of-demeter"
    },
    {
      "id": "2013-06-optimal-logging",
      "title": "Optimal Logging",
      "source_file": "best_practices/2013-06-optimal-logging.md",
      "source_url": "https://testing.googleblog.com/2013/06/optimal-logging.html",
      "published_date": "2013-06-14",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P1_HIGH",
      "summary": "Use structured, leveled logging with contextual attributes; avoid unstructured log spam and repetitive loop logging.",
      "rationale": "Unstructured log spam degrades system throughput and makes searching and diagnosing production incidents painful.",
      "enforcing_prompt": "MANDATORY: Use structured logging (`log/slog` in Go 1.21+). Include typed key-value attributes for searchability. Avoid logging inside tight loops or repeating identical errors.",
      "dos": [
        "Use structured logging with key-value pairs (`slog.Info`, `slog.Error`)",
        "Log once at the appropriate error handling boundary with full context"
      ],
      "donts": [
        "Use unstructured `log.Printf` or `fmt.Println` in production code",
        "Emit repetitive logs on every iteration of a large loop"
      ],
      "linter_rule_id": "go:structured-log"
    },
    {
      "id": "2017-06-code-health-reduce-nesting-reduce",
      "title": "Code Health: Reduce Nesting, Reduce Complexity",
      "source_file": "best_practices/2017-06-code-health-reduce-nesting-reduce.md",
      "source_url": "https://testing.googleblog.com/2017/06/code-health-reduce-nesting-reduce.html",
      "published_date": "2017-06-05",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P1_HIGH",
      "summary": "Minimize indentation depth by using guard clauses, early returns, and extracting complex blocks.",
      "rationale": "Deep nesting forces developers to keep multiple mental branch conditions in working memory simultaneously.",
      "enforcing_prompt": "MANDATORY: Invert conditional statements to return or continue early. Maintain the primary happy path at 0 to 1 indentation levels. If nesting exceeds 3 levels, extract inner blocks into helper functions.",
      "dos": [
        "Handle validation and error cases upfront with guard clauses",
        "Extract nested loops or switch bodies into focused helper functions"
      ],
      "donts": [
        "Wrap entire function bodies inside giant `if ... { ... }` blocks",
        "Nest conditional statements more than 3 levels deep"
      ],
      "linter_rule_id": "go:reduce-nesting"
    },
    {
      "id": "2018-07-code-health-make-interfaces-hard-to",
      "title": "Code Health: Make Interfaces Hard to Misuse",
      "source_file": "best_practices/2018-07-code-health-make-interfaces-hard-to.md",
      "source_url": "https://testing.googleblog.com/2018/07/code-health-make-interfaces-hard-to.html",
      "published_date": "2018-07-25",
      "language_scope": "universal",
      "category_id": "interface_design",
      "priority": "P1_HIGH",
      "summary": "Design interfaces and function signatures that make misuse and incorrect invocations impossible at compile time.",
      "rationale": "Weak parameter types and hidden temporal dependencies cause subtle runtime bugs and poor developer ergonomics.",
      "enforcing_prompt": "MANDATORY: Use strong types (e.g. `time.Duration` instead of `int`) and avoid boolean argument traps (`fn(true, false)`). Design factory constructors that return fully initialized, ready-to-use objects.",
      "dos": [
        "Use `time.Duration` for all time quantities",
        "Use typed enums or configuration structs in place of boolean argument traps"
      ],
      "donts": [
        "Pass raw integers for timeouts or delays (`timeoutMs int`)",
        "Require callers to execute custom manual initialization sequences"
      ],
      "linter_rule_id": "go:boolean-argument-trap"
    },
    {
      "id": "2023-04-sensenmann-code-deletion-at-scale",
      "title": "Sensenmann: Code Deletion at Scale",
      "source_file": "best_practices/2023-04-sensenmann-code-deletion-at-scale.md",
      "source_url": "https://testing.googleblog.com/2023/04/sensenmann-code-deletion-at-scale.html",
      "published_date": "2023-04-28",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P1_HIGH",
      "summary": "Aggressively delete dead code, obsolete feature flags, and unused tests to reduce maintenance overhead.",
      "rationale": "Dead code continues to impose mental burden, slows down refactoring migrations, and wastes CI build cycles.",
      "enforcing_prompt": "MANDATORY: Delete obsolete code, unused functions, expired feature flags, and stale tests immediately rather than commenting them out or leaving them orphaned.",
      "dos": [
        "Remove dead functions, types, and unused packages completely",
        "Clean up expired feature flag branches and their associated legacy paths"
      ],
      "donts": [
        "Leave commented-out legacy code blocks in the repository",
        "Retain dead code 'just in case' it might be needed in the future"
      ]
    },
    {
      "id": "2023-09-else-nuances",
      "title": "Else Nuances",
      "source_file": "best_practices/2023-09-else-nuances.md",
      "source_url": "https://testing.googleblog.com/2023/09/else-nuances.html",
      "published_date": "2023-09-13",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P1_HIGH",
      "summary": "Eliminate redundant 'else' blocks following terminal statements (return, panic, break, continue).",
      "rationale": "Dangling else blocks after terminal statements create unnecessary indentation and visual clutter.",
      "enforcing_prompt": "MANDATORY: Never write an `else` or `else if` block immediately after a branch ending in `return`, `panic`, `break`, or `continue`. Dedent the subsequent statements.",
      "dos": [
        "Dedent and flatten subsequent logic following terminal statements",
        "Use switch statements for multi-way branching"
      ],
      "donts": [
        "Write `if cond { return A } else { return B }`",
        "Maintain unnecessary else blocks around fallback return values"
      ],
      "linter_rule_id": "go:redundant-else"
    },
    {
      "id": "2023-10-improve-readability-with-positive",
      "title": "Improve Readability With Positive Booleans",
      "source_file": "best_practices/2023-10-improve-readability-with-positive.md",
      "source_url": "https://testing.googleblog.com/2023/10/improve-readability-with-positive.html",
      "published_date": "2023-10-17",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P1_HIGH",
      "summary": "Name boolean variables and predicates with positive semantics to prevent double-negative confusion.",
      "rationale": "Negative names combined with boolean operators (`!isNotAuthorized`) require mental inversion, increasing error rates.",
      "enforcing_prompt": "MANDATORY: Name all boolean flags, struct fields, and functions with positive semantics (e.g. `isValid`, `isEnabled`, `hasAccess`). Avoid negative prefixes like `isNot*`, `isDis*`, `un*`, or `isInvalid`.",
      "dos": [
        "Use positive identifiers like `isEnabled`, `isAuthorized`, `allowAnonymous`",
        "Invert logic naturally using the `!` operator on positive flags"
      ],
      "donts": [
        "Declare variables named `isNotValid`, `disabled = false`, or `isUnauthorized`",
        "Combine negative boolean identifiers with logical NOT (`!isNotDisabled`)"
      ],
      "linter_rule_id": "go:positive-booleans"
    },
    {
      "id": "2023-10-simplify-your-control-flows",
      "title": "Simplify Your Control Flows",
      "source_file": "best_practices/2023-10-simplify-your-control-flows.md",
      "source_url": "https://testing.googleblog.com/2023/10/simplify-your-control-flows.html",
      "published_date": "2023-10-24",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P1_HIGH",
      "summary": "Minimize indentation depth by using guard clauses, early returns, and extracting complex blocks.",
      "rationale": "Deep nesting forces developers to keep multiple mental branch conditions in working memory simultaneously.",
      "enforcing_prompt": "MANDATORY: Invert conditional statements to return or continue early. Maintain the primary happy path at 0 to 1 indentation levels. If nesting exceeds 3 levels, extract inner blocks into helper functions.",
      "dos": [
        "Handle validation and error cases upfront with guard clauses",
        "Extract nested loops or switch bodies into focused helper functions"
      ],
      "donts": [
        "Wrap entire function bodies inside giant `if ... { ... }` blocks",
        "Nest conditional statements more than 3 levels deep"
      ],
      "linter_rule_id": "go:reduce-nesting"
    },
    {
      "id": "2023-12-let-code-speak-for-itself",
      "title": "Let Code Speak for Itself",
      "source_file": "best_practices/2023-12-let-code-speak-for-itself.md",
      "source_url": "https://testing.googleblog.com/2023/12/let-code-speak-for-itself.html",
      "published_date": "2023-12-12",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P1_HIGH",
      "summary": "Make code self-explanatory through unambiguous naming and clean structure; write comments strictly to explain 'WHY'.",
      "rationale": "Comments that merely describe what the code does drift out of date, add noise, and mask poor variable naming.",
      "enforcing_prompt": "MANDATORY: Do not write comments that describe what code does. Express intent through clear variable and function names. Reserve comments strictly for explaining WHY (non-obvious constraints, business edge-cases, bug workarounds).",
      "dos": [
        "Choose descriptive identifiers that make code readable as natural language",
        "Document external constraints, unusual trade-offs, and bug workaround rationales"
      ],
      "donts": [
        "Write comments that merely translate code syntax into English",
        "Leave stale or misleading comments in the codebase"
      ],
      "linter_rule_id": "go:naked-return"
    },
    {
      "id": "2024-04-isbooleantoolongandcomplex",
      "title": "isBooleanTooLongAndComplex",
      "source_file": "best_practices/2024-04-isbooleantoolongandcomplex.md",
      "source_url": "https://testing.googleblog.com/2024/04/isbooleantoolongandcomplex.html",
      "published_date": "2024-04-25",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P1_HIGH",
      "summary": "Decompose complex multi-operator boolean expressions into descriptive explanatory variables.",
      "rationale": "Compound conditions with 3+ logical operators (`\u0026\u0026`, `||`) obscure business intent and lead to precedence bugs.",
      "enforcing_prompt": "MANDATORY: If a boolean expression contains 3 or more logical operators, break it down into well-named intermediate boolean variables or extract it into an explanatory predicate function.",
      "dos": [
        "Assign sub-conditions to descriptive variables (`isEligibleForDiscount := ...`)",
        "Extract complex domain condition evaluations into separate predicate methods"
      ],
      "donts": [
        "Write long compound boolean chains across multiple lines inside a single if statement",
        "Mix `\u0026\u0026` and `||` operators without explicit grouping parentheses"
      ],
      "linter_rule_id": "go:boolean-complexity"
    },
    {
      "id": "2024-04-prefer-narrow-assertions-in-unit-tests",
      "title": "Prefer Narrow Assertions in Unit Tests",
      "source_file": "best_practices/2024-04-prefer-narrow-assertions-in-unit-tests.md",
      "source_url": "https://testing.googleblog.com/2024/04/prefer-narrow-assertions-in-unit-tests.html",
      "published_date": "2024-04-04",
      "language_scope": "universal",
      "category_id": "test_design",
      "priority": "P1_HIGH",
      "summary": "Use narrow, targeted assertions focused on the specific behavior under test rather than broad whole-object equality.",
      "rationale": "Broad assertions fail when unrelated default fields change and produce difficult-to-debug diff dumps.",
      "enforcing_prompt": "MANDATORY: Assert specifically on the exact fields or outputs modified by the test case. Avoid giant object comparison assertions unless verifying comprehensive end-to-end payload fidelity.",
      "dos": [
        "Assert on specific expected return fields or state changes",
        "Provide descriptive assertion failure messages that clarify root cause"
      ],
      "donts": [
        "Compare entire serialized structs or JSON blobs when only 1-2 fields matter",
        "Write broad assertions that break on unrelated field additions"
      ]
    },
    {
      "id": "2024-05-dont-dry-your-code-prematurely",
      "title": "Don't DRY Your Code Prematurely",
      "source_file": "best_practices/2024-05-dont-dry-your-code-prematurely.md",
      "source_url": "https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html",
      "published_date": "2024-05-28",
      "language_scope": "universal",
      "category_id": "design_principles",
      "priority": "P1_HIGH",
      "summary": "Avoid premature DRY abstractions; tolerate small, localized duplication until a true, stable pattern emerges.",
      "rationale": "The wrong abstraction is far more expensive to maintain and untangle than a few duplicated lines of code.",
      "enforcing_prompt": "MANDATORY: Do not extract shared abstractions or polymorphic hierarchies until at least 3 distinct use-cases clearly demonstrate identical evolution requirements. Keep evolving behaviors decoupled.",
      "dos": [
        "Allow new features to develop independently before unifying code",
        "Refactor into shared abstractions only after patterns stabilize across multiple implementations"
      ],
      "donts": [
        "Force two loosely similar modules into a rigid shared base class or interface",
        "Create overly generic 'Common' or 'Util' frameworks prematurely"
      ]
    },
    {
      "id": "2024-05-test-failures-should-be-actionable",
      "title": "Test Failures Should Be Actionable",
      "source_file": "best_practices/2024-05-test-failures-should-be-actionable.md",
      "source_url": "https://testing.googleblog.com/2024/05/test-failures-should-be-actionable.html",
      "published_date": "2024-05-06",
      "language_scope": "universal",
      "category_id": "test_design",
      "priority": "P1_HIGH",
      "summary": "Design test failure outputs to be immediately actionable, clearly detailing Expected, Actual, and context.",
      "rationale": "Ambiguous test failure outputs force engineers to attach debuggers or add print statements to diagnose CI breakages.",
      "enforcing_prompt": "MANDATORY: Ensure test failure messages clearly state what was expected, what was actually received, and the specific input parameters that triggered the failure.",
      "dos": [
        "Format failure messages with clear `got = %v, want = %v` and input context",
        "Include domain identifiers in failure outputs"
      ],
      "donts": [
        "Rely on generic assertion failures without explanatory context",
        "Produce silent test failures or swallowed errors in test helpers"
      ]
    },
    {
      "id": "2024-07-in-praise-of-small-pull-requests",
      "title": "In Praise of Small Pull Requests",
      "source_file": "best_practices/2024-07-in-praise-of-small-pull-requests.md",
      "source_url": "https://testing.googleblog.com/2024/07/in-praise-of-small-pull-requests.html",
      "published_date": "2024-07-16",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P1_HIGH",
      "summary": "Keep pull requests small, single-purpose, and easy to review (\u003c 200-300 lines of delta).",
      "rationale": "Small changes are reviewed thoroughly, merge quickly, catch more defects, and are trivial to roll back.",
      "enforcing_prompt": "MANDATORY: Split large tasks into small, self-contained pull requests focusing on a single concern. Never bundle unrelated refactorings or cleanups with functional feature additions.",
      "dos": [
        "Submit atomic, well-scoped pull requests (\u003c 300 lines of change)",
        "Break multi-step initiatives into a sequence of small, reviewable PRs"
      ],
      "donts": [
        "Submit giant multi-thousand-line monolithic changes",
        "Mix formatting cleanups, refactorings, and new features in a single PR"
      ]
    },
    {
      "id": "2025-10-simplify-your-code-functional-core",
      "title": "Simplify Your Code: Functional Core, Imperative Shell",
      "source_file": "best_practices/2025-10-simplify-your-code-functional-core.md",
      "source_url": "https://testing.googleblog.com/2025/10/simplify-your-code-functional-core.html",
      "published_date": "2025-10-20",
      "language_scope": "universal",
      "category_id": "functions_and_data",
      "priority": "P1_HIGH",
      "summary": "Architect code with a pure, side-effect-free Functional Core and an Imperative Shell for I/O orchestration.",
      "rationale": "Pure functions that take data and return data are trivial to test, reason about, and execute concurrently.",
      "enforcing_prompt": "MANDATORY: Separate pure algorithmic and business calculation logic (functional core) from database, network, and disk I/O operations (imperative shell). Ensure core decision logic does not perform side effects.",
      "dos": [
        "Write deterministic calculation functions that accept immutable inputs and return results without I/O",
        "Perform database queries and API calls in the outer orchestration layer"
      ],
      "donts": [
        "Interleave DB queries, file reads, and HTTP calls inside core mathematical or business decision algorithms"
      ]
    },
    {
      "id": "2026-05-construct-with-collaborators-call-with",
      "title": "Construct with Collaborators, Call with Work",
      "source_file": "best_practices/2026-05-construct-with-collaborators-call-with.md",
      "source_url": "https://testing.googleblog.com/2026/05/construct-with-collaborators-call-with.html",
      "published_date": "2026-05-05",
      "language_scope": "universal",
      "category_id": "interface_design",
      "priority": "P1_HIGH",
      "summary": "Pass long-lived service dependencies into constructors; pass per-request data into method execution calls.",
      "rationale": "Passing collaborators to individual methods pollutes signatures and leaks infrastructure concerns into business logic.",
      "enforcing_prompt": "MANDATORY: Inject persistent services/clients (collaborators like DB, Logger, HTTP Client) via constructor/factory functions (`NewService(...)`). Pass dynamic request parameters (`ctx`, `payload`, `userID`) into method calls.",
      "dos": [
        "Inject infrastructure dependencies at struct instantiation time",
        "Pass request-scoped context and data to method calls"
      ],
      "donts": [
        "Pass database handles or network clients as parameters to domain methods",
        "Instantiate new long-lived infrastructure clients inside business methods"
      ],
      "linter_rule_id": "go:inline-dependency-creation"
    },
    {
      "id": "2026-07-prefactoring-clear-way-for-your-new",
      "title": "Prefactoring: Clear the Way for Your New Feature",
      "source_file": "best_practices/2026-07-prefactoring-clear-way-for-your-new.md",
      "source_url": "https://testing.googleblog.com/2026/07/prefactoring-clear-way-for-your-new.html",
      "published_date": "2026-07-21",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P1_HIGH",
      "summary": "Prefactor existing code in a separate preliminary change to make the upcoming feature easy to implement.",
      "rationale": "Combining structural code restructuring and new business logic in a single change makes code reviews arduous and bug-prone.",
      "enforcing_prompt": "MANDATORY: Refactor first to prepare the codebase (prefactor commit/PR), then implement the new feature cleanly on top of the restructured base. Keep structural and behavioral changes strictly separate.",
      "dos": [
        "Submit a dedicated preparatory cleanup PR before starting feature implementation",
        "Ensure test suites pass before and after each prefactoring step"
      ],
      "donts": [
        "Force new features into poorly structured existing code without prefactoring",
        "Combine architectural refactorings and new business logic into one commit"
      ]
    },
    {
      "id": "2007-01-better-stubbing-in-python",
      "title": "TotT: Better Stubbing in Python",
      "source_file": "best_practices/2007-01-better-stubbing-in-python.md",
      "source_url": "https://testing.googleblog.com/2007/01/better-stubbing-in-python.html",
      "published_date": "2007-01-24",
      "language_scope": "python",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "You could avoid this problem by stubbing or mocking out DoSomethingElse, but the task might be",
      "rationale": "Core engineering principle derived from: TotT: Better Stubbing in Python.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'TotT: Better Stubbing in Python'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Better Stubbing in Python"
      ],
      "donts": [
        "Violate the principle: You could avoid this problem by stubbing or mocking out DoSomethingElse, but the task might be"
      ]
    },
    {
      "id": "2007-02-tott-naming-unit-tests-responsibly",
      "title": "TotT: Naming Unit Tests Responsibly",
      "source_file": "best_practices/2007-02-tott-naming-unit-tests-responsibly.md",
      "source_url": "https://testing.googleblog.com/2007/02/tott-naming-unit-tests-responsibly.html",
      "published_date": "2007-02-01",
      "language_scope": "universal",
      "category_id": "test_design",
      "priority": "P2_MEDIUM",
      "summary": "These naming conventions can help point out smells.",
      "rationale": "Core engineering principle derived from: TotT: Naming Unit Tests Responsibly.",
      "enforcing_prompt": "RECOMMENDED: Apply test design practice 'TotT: Naming Unit Tests Responsibly'. Ensure test assertions are narrow, descriptive, and actionable.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Naming Unit Tests Responsibly"
      ],
      "donts": [
        "Violate the principle: These naming conventions can help point out smells."
      ]
    },
    {
      "id": "2007-04-tott-refactoring-tests-in-red",
      "title": "TotT: Refactoring Tests in the Red",
      "source_file": "best_practices/2007-04-tott-refactoring-tests-in-red.md",
      "source_url": "https://testing.googleblog.com/2007/04/tott-refactoring-tests-in-red.html",
      "published_date": "2007-04-26",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Like any code, tests should ideally be kept in a state that's easy to understand and maintain.",
      "rationale": "Core engineering principle derived from: TotT: Refactoring Tests in the Red.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: Refactoring Tests in the Red'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Refactoring Tests in the Red"
      ],
      "donts": [
        "Violate the principle: Like any code, tests should ideally be kept in a state that's easy to understand and maintain."
      ]
    },
    {
      "id": "2007-04-tott-stubs-speed-up-your-unit-tests",
      "title": "TotT: Stubs Speed up Your Unit Tests",
      "source_file": "best_practices/2007-04-tott-stubs-speed-up-your-unit-tests.md",
      "source_url": "https://testing.googleblog.com/2007/04/tott-stubs-speed-up-your-unit-tests.html",
      "published_date": "2007-04-04",
      "language_scope": "universal",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "Test Double is a generic term for any test object that replaces a production object.",
      "rationale": "Core engineering principle derived from: TotT: Stubs Speed up Your Unit Tests.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'TotT: Stubs Speed up Your Unit Tests'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Stubs Speed up Your Unit Tests"
      ],
      "donts": [
        "Violate the principle: Test Double is a generic term for any test object that replaces a production object."
      ]
    },
    {
      "id": "2007-05-sign-up-to-attend-our-test-automation",
      "title": "Sign up to attend our Test Automation Conference",
      "source_file": "best_practices/2007-05-sign-up-to-attend-our-test-automation.md",
      "source_url": "https://testing.googleblog.com/2007/05/sign-up-to-attend-our-test-automation.html",
      "published_date": "2007-05-23",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Today, I'm happy to tell you that we've finalized the speaker list and have opened the attendee",
      "rationale": "Core engineering principle derived from: Sign up to attend our Test Automation Conference.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Sign up to attend our Test Automation Conference'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Sign up to attend our Test Automation Conference"
      ],
      "donts": [
        "Violate the principle: Today, I'm happy to tell you that we've finalized the speaker list and have opened the attendee"
      ]
    },
    {
      "id": "2007-06-tott-extracting-methods-to-simplify",
      "title": "TotT: Extracting Methods to Simplify Testing",
      "source_file": "best_practices/2007-06-tott-extracting-methods-to-simplify.md",
      "source_url": "https://testing.googleblog.com/2007/06/tott-extracting-methods-to-simplify.html",
      "published_date": "2007-06-13",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "When a method is long and complex, it is harder to test.",
      "rationale": "Core engineering principle derived from: TotT: Extracting Methods to Simplify Testing.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: Extracting Methods to Simplify Testing'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Extracting Methods to Simplify Testing"
      ],
      "donts": [
        "Violate the principle: When a method is long and complex, it is harder to test."
      ]
    },
    {
      "id": "2007-09-but-it-works-on-my-machine",
      "title": "But it works on my machine!",
      "source_file": "best_practices/2007-09-but-it-works-on-my-machine.md",
      "source_url": "https://testing.googleblog.com/2007/09/but-it-works-on-my-machine.html",
      "published_date": "2007-09-25",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "But I have a gazillion unit tests and I don't need system level tests!",
      "rationale": "Core engineering principle derived from: But it works on my machine!.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'But it works on my machine!'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in But it works on my machine!"
      ],
      "donts": [
        "Violate the principle: But I have a gazillion unit tests and I don't need system level tests!"
      ]
    },
    {
      "id": "2007-09-seleniums-inventor",
      "title": "Selenium's Inventor",
      "source_file": "best_practices/2007-09-seleniums-inventor.md",
      "source_url": "https://testing.googleblog.com/2007/09/seleniums-inventor.html",
      "published_date": "2007-09-19",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "One way to bring the test run times down is to run them in parallel on a grid of servers, instead",
      "rationale": "Core engineering principle derived from: Selenium's Inventor.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Selenium's Inventor'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Selenium's Inventor"
      ],
      "donts": [
        "Violate the principle: One way to bring the test run times down is to run them in parallel on a grid of servers, instead"
      ]
    },
    {
      "id": "2007-09-testing-applications-and-apis",
      "title": "Testing Applications and APIs",
      "source_file": "best_practices/2007-09-testing-applications-and-apis.md",
      "source_url": "https://testing.googleblog.com/2007/09/testing-applications-and-apis.html",
      "published_date": "2007-09-14",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Adding fuzz to the parameters and call patterns can help, but not eliminate, this problem.",
      "rationale": "Core engineering principle derived from: Testing Applications and APIs.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Testing Applications and APIs'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Testing Applications and APIs"
      ],
      "donts": [
        "Violate the principle: Adding fuzz to the parameters and call patterns can help, but not eliminate, this problem."
      ]
    },
    {
      "id": "2007-10-automating-tests-vs-test-automation",
      "title": "Automating tests vs. test-automation",
      "source_file": "best_practices/2007-10-automating-tests-vs-test-automation.md",
      "source_url": "https://testing.googleblog.com/2007/10/automating-tests-vs-test-automation.html",
      "published_date": "2007-10-24",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "If so, it should be tested through the API, and the UI should just be checked to interact with the",
      "rationale": "Core engineering principle derived from: Automating tests vs. test-automation.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Automating tests vs. test-automation'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Automating tests vs. test-automation"
      ],
      "donts": [
        "Violate the principle: If so, it should be tested through the API, and the UI should just be checked to interact with the"
      ]
    },
    {
      "id": "2007-10-performance-testing",
      "title": "Performance Testing",
      "source_file": "best_practices/2007-10-performance-testing.md",
      "source_url": "https://testing.googleblog.com/2007/10/performance-testing.html",
      "published_date": "2007-10-08",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "If you do not have service related monitoring developed and set up to be used during live",
      "rationale": "Core engineering principle derived from: Performance Testing.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Performance Testing'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Performance Testing"
      ],
      "donts": [
        "Violate the principle: If you do not have service related monitoring developed and set up to be used during live"
      ]
    },
    {
      "id": "2007-10-tott-avoiding-friend-twister-in-c",
      "title": "TotT: Avoiding friend Twister in C++",
      "source_file": "best_practices/2007-10-tott-avoiding-friend-twister-in-c.md",
      "source_url": "https://testing.googleblog.com/2007/10/tott-avoiding-friend-twister-in-c.html",
      "published_date": "2007-10-30",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "In a previous episode, we extracted methods to simplify testing in Python.",
      "rationale": "Core engineering principle derived from: TotT: Avoiding friend Twister in C++.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: Avoiding friend Twister in C++'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Avoiding friend Twister in C++"
      ],
      "donts": [
        "Violate the principle: In a previous episode, we extracted methods to simplify testing in Python."
      ]
    },
    {
      "id": "2008-02-in-movie-amadeus-austrian-emperor",
      "title": "TotT: Too Many Tests",
      "source_file": "best_practices/2008-02-in-movie-amadeus-austrian-emperor.md",
      "source_url": "https://testing.googleblog.com/2008/02/in-movie-amadeus-austrian-emperor.html",
      "published_date": "2008-02-21",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "public void decide(int a, int b, int c, int d, int e, int f) { if (a \u003e b || c \u003e d || e \u003e f) {",
      "rationale": "Core engineering principle derived from: TotT: Too Many Tests.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: Too Many Tests'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Too Many Tests"
      ],
      "donts": [
        "Violate the principle: public void decide(int a, int b, int c, int d, int e, int f) { if (a \u003e b || c \u003e d || e \u003e f) {"
      ]
    },
    {
      "id": "2008-02-tott-stroop-effect",
      "title": "TotT: The Stroop Effect",
      "source_file": "best_practices/2008-02-tott-stroop-effect.md",
      "source_url": "https://testing.googleblog.com/2008/02/tott-stroop-effect.html",
      "published_date": "2008-02-07",
      "language_scope": "universal",
      "category_id": "test_design",
      "priority": "P2_MEDIUM",
      "summary": "Failure: testProtanopiaColorMatcherCannotDistinguishBetweenCertainPairsOfColorsMessage: BLUE and",
      "rationale": "Core engineering principle derived from: TotT: The Stroop Effect.",
      "enforcing_prompt": "RECOMMENDED: Apply test design practice 'TotT: The Stroop Effect'. Ensure test assertions are narrow, descriptive, and actionable.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: The Stroop Effect"
      ],
      "donts": [
        "Violate the principle: Failure: testProtanopiaColorMatcherCannotDistinguishBetweenCertainPairsOfColorsMessage: BLUE and"
      ]
    },
    {
      "id": "2008-03-cost-benefit-analysis-of-test",
      "title": "Cost-Benefit Analysis of a Test",
      "source_file": "best_practices/2008-03-cost-benefit-analysis-of-test.md",
      "source_url": "https://testing.googleblog.com/2008/03/cost-benefit-analysis-of-test.html",
      "published_date": "2008-03-12",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "This cost should be balanced against the benefits of the test when deciding whether a test should",
      "rationale": "Core engineering principle derived from: Cost-Benefit Analysis of a Test.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Cost-Benefit Analysis of a Test'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Cost-Benefit Analysis of a Test"
      ],
      "donts": [
        "Violate the principle: This cost should be balanced against the benefits of the test when deciding whether a test should"
      ]
    },
    {
      "id": "2008-03-tott-testng-on-toilet",
      "title": "TotT: TestNG on the Toilet",
      "source_file": "best_practices/2008-03-tott-testng-on-toilet.md",
      "source_url": "https://testing.googleblog.com/2008/03/tott-testng-on-toilet.html",
      "published_date": "2008-03-20",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "The elements in the array represent // parameters to the test call.",
      "rationale": "Core engineering principle derived from: TotT: TestNG on the Toilet.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: TestNG on the Toilet'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: TestNG on the Toilet"
      ],
      "donts": [
        "Violate the principle: The elements in the array represent // parameters to the test call."
      ]
    },
    {
      "id": "2008-03-tott-understanding-your-coverage-data",
      "title": "TotT: Understanding Your Coverage Data",
      "source_file": "best_practices/2008-03-tott-understanding-your-coverage-data.md",
      "source_url": "https://testing.googleblog.com/2008/03/tott-understanding-your-coverage-data.html",
      "published_date": "2008-03-06",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Some tools do not provide fractional coverage.",
      "rationale": "Core engineering principle derived from: TotT: Understanding Your Coverage Data.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: Understanding Your Coverage Data'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Understanding Your Coverage Data"
      ],
      "donts": [
        "Violate the principle: Some tools do not provide fractional coverage."
      ]
    },
    {
      "id": "2008-05-exploratory-testing-on-chat",
      "title": "Exploratory Testing on Chat",
      "source_file": "best_practices/2008-05-exploratory-testing-on-chat.md",
      "source_url": "https://testing.googleblog.com/2008/05/exploratory-testing-on-chat.html",
      "published_date": "2008-05-20",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Testing Google Talk is challenging -- we have multiple client implementations, between the Google",
      "rationale": "Core engineering principle derived from: Exploratory Testing on Chat.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Exploratory Testing on Chat'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Exploratory Testing on Chat"
      ],
      "donts": [
        "Violate the principle: Testing Google Talk is challenging -- we have multiple client implementations, between the Google"
      ]
    },
    {
      "id": "2008-05-performance-testing-of-distributed-file",
      "title": "Performance Testing of Distributed File Systems at Google",
      "source_file": "best_practices/2008-05-performance-testing-of-distributed-file.md",
      "source_url": "https://testing.googleblog.com/2008/05/performance-testing-of-distributed-file.html",
      "published_date": "2008-05-31",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Unified testing: The framework should be stand-alone or independent ie it should be a one-stop",
      "rationale": "Core engineering principle derived from: Performance Testing of Distributed File Systems at Google.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Performance Testing of Distributed File Systems at Google'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Performance Testing of Distributed File Systems at Google"
      ],
      "donts": [
        "Violate the principle: Unified testing: The framework should be stand-alone or independent ie it should be a one-stop"
      ]
    },
    {
      "id": "2008-05-tott-invisible-branch",
      "title": "TotT: The Invisible Branch",
      "source_file": "best_practices/2008-05-tott-invisible-branch.md",
      "source_url": "https://testing.googleblog.com/2008/05/tott-invisible-branch.html",
      "published_date": "2008-05-28",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "If you were to draw a flowchart of both snippets (left as an exercise - and we recommend against",
      "rationale": "Core engineering principle derived from: TotT: The Invisible Branch.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: The Invisible Branch'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: The Invisible Branch"
      ],
      "donts": [
        "Violate the principle: If you were to draw a flowchart of both snippets (left as an exercise - and we recommend against"
      ]
    },
    {
      "id": "2008-05-tott-testable-contracts-make",
      "title": "TotT: Testable Contracts Make Exceptional Neighbors",
      "source_file": "best_practices/2008-05-tott-testable-contracts-make.md",
      "source_url": "https://testing.googleblog.com/2008/05/tott-testable-contracts-make.html",
      "published_date": "2008-05-01",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "bool SomeCollection::GetObjects(vector* objects) const { objects-\u003eclear(); typedef",
      "rationale": "Core engineering principle derived from: TotT: Testable Contracts Make Exceptional Neighbors.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: Testable Contracts Make Exceptional Neighbors'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Testable Contracts Make Exceptional Neighbors"
      ],
      "donts": [
        "Violate the principle: bool SomeCollection::GetObjects(vector* objects) const { objects-\u003eclear(); typedef"
      ]
    },
    {
      "id": "2008-06-productivity-games-using-games-to",
      "title": "Productivity Games - Using Games to Improve Quality",
      "source_file": "best_practices/2008-06-productivity-games-using-games-to.md",
      "source_url": "https://testing.googleblog.com/2008/06/productivity-games-using-games-to.html",
      "published_date": "2008-06-21",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Successful game design is best achieved through experience and experimentation, and the goal",
      "rationale": "Core engineering principle derived from: Productivity Games - Using Games to Improve Quality.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Productivity Games - Using Games to Improve Quality'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Productivity Games - Using Games to Improve Quality"
      ],
      "donts": [
        "Violate the principle: Successful game design is best achieved through experience and experimentation, and the goal"
      ]
    },
    {
      "id": "2008-06-taming-beast-aka-how-to-test-ajax",
      "title": "Taming the Beast (a.k.a. how to test AJAX applications) : Part 1",
      "source_file": "best_practices/2008-06-taming-beast-aka-how-to-test-ajax.md",
      "source_url": "https://testing.googleblog.com/2008/06/taming-beast-aka-how-to-test-ajax.html",
      "published_date": "2008-06-13",
      "language_scope": "universal",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "don't give confidence that the business logic and functionality of the system meets the",
      "rationale": "Core engineering principle derived from: Taming the Beast (a.k.a. how to test AJAX applications) : Part 1.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'Taming the Beast (a.k.a. how to test AJAX applications) : Part 1'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in Taming the Beast (a.k.a. how to test AJAX applications) : Part 1"
      ],
      "donts": [
        "Violate the principle: don't give confidence that the business logic and functionality of the system meets the"
      ]
    },
    {
      "id": "2008-06-test-engineering-class-project-at-uc",
      "title": "Test Engineering Class Project at UC-Irivine",
      "source_file": "best_practices/2008-06-test-engineering-class-project-at-uc.md",
      "source_url": "https://testing.googleblog.com/2008/06/test-engineering-class-project-at-uc.html",
      "published_date": "2008-06-24",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Test Reporting - The examination of test results.",
      "rationale": "Core engineering principle derived from: Test Engineering Class Project at UC-Irivine.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Test Engineering Class Project at UC-Irivine'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Test Engineering Class Project at UC-Irivine"
      ],
      "donts": [
        "Violate the principle: Test Reporting - The examination of test results."
      ]
    },
    {
      "id": "2008-06-tott-friends-you-can-depend-on",
      "title": "TotT: Friends You Can Depend On",
      "source_file": "best_practices/2008-06-tott-friends-you-can-depend-on.md",
      "source_url": "https://testing.googleblog.com/2008/06/tott-friends-you-can-depend-on.html",
      "published_date": "2008-06-12",
      "language_scope": "universal",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "A Mock can return values, but it also cares about the way its methods are called (\"strict",
      "rationale": "Core engineering principle derived from: TotT: Friends You Can Depend On.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'TotT: Friends You Can Depend On'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Friends You Can Depend On"
      ],
      "donts": [
        "Violate the principle: A Mock can return values, but it also cares about the way its methods are called (\"strict"
      ]
    },
    {
      "id": "2008-07-announcing-new-google-c-testing",
      "title": "Announcing: New Google C++ Testing Framework",
      "source_file": "best_practices/2008-07-announcing-new-google-c-testing.md",
      "source_url": "https://testing.googleblog.com/2008/07/announcing-new-google-c-testing.html",
      "published_date": "2008-07-03",
      "language_scope": "cpp",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "On Linux, you can write death tests to ensure that your code crashes with expected errors.",
      "rationale": "Core engineering principle derived from: Announcing: New Google C++ Testing Framework.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Announcing: New Google C++ Testing Framework'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Announcing: New Google C++ Testing Framework"
      ],
      "donts": [
        "Violate the principle: On Linux, you can write death tests to ensure that your code crashes with expected errors."
      ]
    },
    {
      "id": "2008-07-how-to-write-3v1l-untestable-code",
      "title": "How to Write 3v1L, Untestable Code",
      "source_file": "best_practices/2008-07-how-to-write-3v1l-untestable-code.md",
      "source_url": "https://testing.googleblog.com/2008/07/how-to-write-3v1l-untestable-code.html",
      "published_date": "2008-07-24",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "This will prevent others from using your code in ways you don't intend, (like small tests that run",
      "rationale": "Core engineering principle derived from: How to Write 3v1L, Untestable Code.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'How to Write 3v1L, Untestable Code'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in How to Write 3v1L, Untestable Code"
      ],
      "donts": [
        "Violate the principle: This will prevent others from using your code in ways you don't intend, (like small tests that run"
      ]
    },
    {
      "id": "2008-07-tott-expect-vs-assert",
      "title": "TotT: EXPECT vs. ASSERT",
      "source_file": "best_practices/2008-07-tott-expect-vs-assert.md",
      "source_url": "https://testing.googleblog.com/2008/07/tott-expect-vs-assert.html",
      "published_date": "2008-07-10",
      "language_scope": "universal",
      "category_id": "test_design",
      "priority": "P2_MEDIUM",
      "summary": "Distinguish between fatal preconditions (ASSERT / t.Fatal) and non-fatal property checks (EXPECT / t.Error).",
      "rationale": "Failing fast on nil pointers prevents test panics; continuing on independent checks provides a complete failure report.",
      "enforcing_prompt": "RECOMMENDED: Use fatal assertions (`t.Fatalf` / ASSERT) for nil checks, setup preconditions, and non-recoverable errors. Use non-fatal checks (`t.Errorf` / EXPECT) for independent property evaluations.",
      "dos": [
        "Use `t.Fatalf` when continuing the test execution would cause a panic",
        "Use `t.Errorf` for multi-field property checks to report all issues in a single test run"
      ],
      "donts": [
        "Continue test execution after a failed nil check or initialization error"
      ]
    },
    {
      "id": "2008-08-by-miko-hevery-so-you-decided-to",
      "title": "Writing Testable Code",
      "source_file": "best_practices/2008-08-by-miko-hevery-so-you-decided-to.md",
      "source_url": "https://testing.googleblog.com/2008/08/by-miko-hevery-so-you-decided-to.html",
      "published_date": "2008-08-06",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Finally don't mix the responsibility of work with configuration, If you are an Authenticator class",
      "rationale": "Core engineering principle derived from: Writing Testable Code.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Writing Testable Code'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Writing Testable Code"
      ],
      "donts": [
        "Violate the principle: Finally don't mix the responsibility of work with configuration, If you are an Authenticator class"
      ]
    },
    {
      "id": "2008-08-by-miko-hevery-so-you-join-new-project",
      "title": "Singletons are Pathological Liars",
      "source_file": "best_practices/2008-08-by-miko-hevery-so-you-join-new-project.md",
      "source_url": "https://testing.googleblog.com/2008/08/by-miko-hevery-so-you-join-new-project.html",
      "published_date": "2008-08-17",
      "language_scope": "universal",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "The best benefit is that now, you have seams where you can mock out the collaborators so that you",
      "rationale": "Core engineering principle derived from: Singletons are Pathological Liars.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'Singletons are Pathological Liars'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in Singletons are Pathological Liars"
      ],
      "donts": [
        "Violate the principle: The best benefit is that now, you have seams where you can mock out the collaborators so that you"
      ]
    },
    {
      "id": "2008-08-progressive-developer-knows-that-in",
      "title": "TotT: A Matter of Black and White",
      "source_file": "best_practices/2008-08-progressive-developer-knows-that-in.md",
      "source_url": "https://testing.googleblog.com/2008/08/progressive-developer-knows-that-in.html",
      "published_date": "2008-08-07",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "We have two groups of black-box tests that verify that images decode correctly: must-have and",
      "rationale": "Core engineering principle derived from: TotT: A Matter of Black and White.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: A Matter of Black and White'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: A Matter of Black and White"
      ],
      "donts": [
        "Violate the principle: We have two groups of black-box tests that verify that images decode correctly: must-have and"
      ]
    },
    {
      "id": "2008-08-taming-beast",
      "title": "Taming the Beast (a.k.a. how to test AJAX applications) : Part 2",
      "source_file": "best_practices/2008-08-taming-beast.md",
      "source_url": "https://testing.googleblog.com/2008/08/taming-beast.html",
      "published_date": "2008-08-27",
      "language_scope": "universal",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "Use dependency injection to swap out real for fake implementations",
      "rationale": "Core engineering principle derived from: Taming the Beast (a.k.a. how to test AJAX applications) : Part 2.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'Taming the Beast (a.k.a. how to test AJAX applications) : Part 2'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in Taming the Beast (a.k.a. how to test AJAX applications) : Part 2"
      ],
      "donts": [
        "Violate the principle: Use dependency injection to swap out real for fake implementations"
      ]
    },
    {
      "id": "2008-08-where-have-all-singletons-gone",
      "title": "Where Have All the Singletons Gone?",
      "source_file": "best_practices/2008-08-where-have-all-singletons-gone.md",
      "source_url": "https://testing.googleblog.com/2008/08/where-have-all-singletons-gone.html",
      "published_date": "2008-08-21",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P2_MEDIUM",
      "summary": "Collaborator Graph: This is the graph of objects that would be emitted if you serialized your",
      "rationale": "Core engineering principle derived from: Where Have All the Singletons Gone?.",
      "enforcing_prompt": "RECOMMENDED: Apply control flow practice 'Where Have All the Singletons Gone?'. Keep control flow flat using guard clauses and early returns.",
      "dos": [
        "Follow the specific architectural guidance outlined in Where Have All the Singletons Gone?"
      ],
      "donts": [
        "Violate the principle: Collaborator Graph: This is the graph of objects that would be emitted if you serialized your"
      ]
    },
    {
      "id": "2008-09-my-main-method-is-better-than-yours",
      "title": "My main() Method Is Better Than Yours",
      "source_file": "best_practices/2008-09-my-main-method-is-better-than-yours.md",
      "source_url": "https://testing.googleblog.com/2008/09/my-main-method-is-better-than-yours.html",
      "published_date": "2008-09-08",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P2_MEDIUM",
      "summary": "But, in order to do that the Factory class should do nothing but object graph construction.",
      "rationale": "Core engineering principle derived from: My main() Method Is Better Than Yours.",
      "enforcing_prompt": "RECOMMENDED: Apply code health practice 'My main() Method Is Better Than Yours'. Maintain clear control flow, concise functions, and high readability.",
      "dos": [
        "Follow the specific architectural guidance outlined in My main() Method Is Better Than Yours"
      ],
      "donts": [
        "Violate the principle: But, in order to do that the Factory class should do nothing but object graph construction."
      ]
    },
    {
      "id": "2008-09-tott-data-driven-traps",
      "title": "TotT: Data Driven Traps!",
      "source_file": "best_practices/2008-09-tott-data-driven-traps.md",
      "source_url": "https://testing.googleblog.com/2008/09/tott-data-driven-traps.html",
      "published_date": "2008-09-04",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "TEST(IsWordTest, IsWordInMultipleLocales) { EXPECT_TRUE(IsWord(\"milk\", Word::UK));",
      "rationale": "Core engineering principle derived from: TotT: Data Driven Traps!.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: Data Driven Traps!'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Data Driven Traps!"
      ],
      "donts": [
        "Violate the principle: TEST(IsWordTest, IsWordInMultipleLocales) { EXPECT_TRUE(IsWord(\"milk\", Word::UK));"
      ]
    },
    {
      "id": "2008-10-dependency-injection-myth-reference",
      "title": "Dependency Injection Myth: Reference Passing",
      "source_file": "best_practices/2008-10-dependency-injection-myth-reference.md",
      "source_url": "https://testing.googleblog.com/2008/10/dependency-injection-myth-reference.html",
      "published_date": "2008-10-22",
      "language_scope": "universal",
      "category_id": "interface_design",
      "priority": "P2_MEDIUM",
      "summary": "So instead of trying to construct the UserRepository itself, it should simply ask for the",
      "rationale": "Core engineering principle derived from: Dependency Injection Myth: Reference Passing.",
      "enforcing_prompt": "RECOMMENDED: Apply API design practice 'Dependency Injection Myth: Reference Passing'. Design hard-to-misuse interfaces and decouple dependencies.",
      "dos": [
        "Follow the specific architectural guidance outlined in Dependency Injection Myth: Reference Passing"
      ],
      "donts": [
        "Violate the principle: So instead of trying to construct the UserRepository itself, it should simply ask for the"
      ]
    },
    {
      "id": "2008-10-testability-explorer-measuring",
      "title": "Testability Explorer: Measuring Testability",
      "source_file": "best_practices/2008-10-testability-explorer-measuring.md",
      "source_url": "https://testing.googleblog.com/2008/10/testability-explorer-measuring.html",
      "published_date": "2008-10-27",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "In order to produce a lasting change in the behavior of developers it helps to have a measurable",
      "rationale": "Core engineering principle derived from: Testability Explorer: Measuring Testability.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Testability Explorer: Measuring Testability'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Testability Explorer: Measuring Testability"
      ],
      "donts": [
        "Violate the principle: In order to produce a lasting change in the behavior of developers it helps to have a measurable"
      ]
    },
    {
      "id": "2008-10-to-new-or-not-to-new",
      "title": "To \\",
      "source_file": "best_practices/2008-10-to-new-or-not-to-new.md",
      "source_url": "https://testing.googleblog.com/2008/10/to-new-or-not-to-new.html",
      "published_date": "2008-10-03",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Is that OK, or should we ask for the Email in our constructor.",
      "rationale": "Core engineering principle derived from: To \\.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'To \\'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in To \\"
      ],
      "donts": [
        "Violate the principle: Is that OK, or should we ask for the Email in our constructor."
      ]
    },
    {
      "id": "2008-11-guide-to-writing-testable-code",
      "title": "Guide to Writing Testable Code",
      "source_file": "best_practices/2008-11-guide-to-writing-testable-code.md",
      "source_url": "https://testing.googleblog.com/2008/11/guide-to-writing-testable-code.html",
      "published_date": "2008-11-26",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "To keep our code at Google in the best possible shape we provided our software engineers with",
      "rationale": "Core engineering principle derived from: Guide to Writing Testable Code.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Guide to Writing Testable Code'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Guide to Writing Testable Code"
      ],
      "donts": [
        "Violate the principle: To keep our code at Google in the best possible shape we provided our software engineers with"
      ]
    },
    {
      "id": "2008-11-my-unified-theory-of-bugs",
      "title": "My Unified Theory of Bugs",
      "source_file": "best_practices/2008-11-my-unified-theory-of-bugs.md",
      "source_url": "https://testing.googleblog.com/2008/11/my-unified-theory-of-bugs.html",
      "published_date": "2008-11-18",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Unit-tests should HELP refactoring not PREVENT refactorings.",
      "rationale": "Core engineering principle derived from: My Unified Theory of Bugs.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'My Unified Theory of Bugs'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in My Unified Theory of Bugs"
      ],
      "donts": [
        "Violate the principle: Unit-tests should HELP refactoring not PREVENT refactorings."
      ]
    },
    {
      "id": "2008-11-posted-by-alex-icev-test-engineering",
      "title": "Online Machine Learning Testing == Extreme Testing",
      "source_file": "best_practices/2008-11-posted-by-alex-icev-test-engineering.md",
      "source_url": "https://testing.googleblog.com/2008/11/posted-by-alex-icev-test-engineering.html",
      "published_date": "2008-11-24",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "-Should this query bring up a maps onebox?",
      "rationale": "Core engineering principle derived from: Online Machine Learning Testing == Extreme Testing.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Online Machine Learning Testing == Extreme Testing'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Online Machine Learning Testing == Extreme Testing"
      ],
      "donts": [
        "Violate the principle: -Should this query bring up a maps onebox?"
      ]
    },
    {
      "id": "2008-11-tott-contain-your-environment",
      "title": "TotT: Finding Data Races in C++",
      "source_file": "best_practices/2008-11-tott-contain-your-environment.md",
      "source_url": "https://testing.googleblog.com/2008/11/tott-contain-your-environment.html",
      "published_date": "2008-11-13",
      "language_scope": "universal",
      "category_id": "functions_and_data",
      "priority": "P2_MEDIUM",
      "summary": "4 int bottles_of_beer = 0; 5 void Intern1() { bottles_of_beer++; } // Intern1 forgot to use Mutex.",
      "rationale": "Core engineering principle derived from: TotT: Finding Data Races in C++.",
      "enforcing_prompt": "RECOMMENDED: Apply function and data practice 'TotT: Finding Data Races in C++'. Optimize data lookup and isolate pure calculation functions.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Finding Data Races in C++"
      ],
      "donts": [
        "Violate the principle: 4 int bottles_of_beer = 0; 5 void Intern1() { bottles_of_beer++; } // Intern1 forgot to use Mutex."
      ]
    },
    {
      "id": "2008-12-mockers-of-c-world-delight",
      "title": "Mockers of the (C++) World, Delight!",
      "source_file": "best_practices/2008-12-mockers-of-c-world-delight.md",
      "source_url": "https://testing.googleblog.com/2008/12/mockers-of-c-world-delight.html",
      "published_date": "2008-12-11",
      "language_scope": "cpp",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "Google Mock has many matchers you can use to precisely specify what the argument should be like.",
      "rationale": "Core engineering principle derived from: Mockers of the (C++) World, Delight!.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'Mockers of the (C++) World, Delight!'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in Mockers of the (C++) World, Delight!"
      ],
      "donts": [
        "Violate the principle: Google Mock has many matchers you can use to precisely specify what the argument should be like."
      ]
    },
    {
      "id": "2009-01-interfacing-with-hard-to-test-third",
      "title": "Interfacing with hard-to-test third-party code",
      "source_file": "best_practices/2009-01-interfacing-with-hard-to-test-third.md",
      "source_url": "https://testing.googleblog.com/2009/01/interfacing-with-hard-to-test-third.html",
      "published_date": "2009-01-07",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Servlets require a no argument constructor which prevents us from using dependency injection.",
      "rationale": "Core engineering principle derived from: Interfacing with hard-to-test third-party code.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Interfacing with hard-to-test third-party code'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Interfacing with hard-to-test third-party code"
      ],
      "donts": [
        "Violate the principle: Servlets require a no argument constructor which prevents us from using dependency injection."
      ]
    },
    {
      "id": "2009-01-when-to-use-dependency-injection",
      "title": "When to use Dependency Injection",
      "source_file": "best_practices/2009-01-when-to-use-dependency-injection.md",
      "source_url": "https://testing.googleblog.com/2009/01/when-to-use-dependency-injection.html",
      "published_date": "2009-01-20",
      "language_scope": "universal",
      "category_id": "interface_design",
      "priority": "P2_MEDIUM",
      "summary": "Should I be using dependency-injection?",
      "rationale": "Core engineering principle derived from: When to use Dependency Injection.",
      "enforcing_prompt": "RECOMMENDED: Apply API design practice 'When to use Dependency Injection'. Design hard-to-misuse interfaces and decouple dependencies.",
      "dos": [
        "Follow the specific architectural guidance outlined in When to use Dependency Injection"
      ],
      "donts": [
        "Violate the principle: Should I be using dependency-injection?"
      ]
    },
    {
      "id": "2009-02-fast-exploratory-tests-with-iframes",
      "title": "Fast exploratory tests with IFrames",
      "source_file": "best_practices/2009-02-fast-exploratory-tests-with-iframes.md",
      "source_url": "https://testing.googleblog.com/2009/02/fast-exploratory-tests-with-iframes.html",
      "published_date": "2009-02-20",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "(Warning: Do not try this with YouTube, as 43 Flash windows on the same pages will crash your",
      "rationale": "Core engineering principle derived from: Fast exploratory tests with IFrames.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Fast exploratory tests with IFrames'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Fast exploratory tests with IFrames"
      ],
      "donts": [
        "Violate the principle: (Warning: Do not try this with YouTube, as 43 Flash windows on the same pages will crash your"
      ]
    },
    {
      "id": "2009-02-tott-partial-mocks-using-forwarding_19",
      "title": "TotT: Partial Mocks using Forwarding Objects",
      "source_file": "best_practices/2009-02-tott-partial-mocks-using-forwarding_19.md",
      "source_url": "https://testing.googleblog.com/2009/02/tott-partial-mocks-using-forwarding_19.html",
      "published_date": "2009-02-19",
      "language_scope": "universal",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "It allows us to use the OlympicDuck's location logic instead of rewriting/simulating the logic",
      "rationale": "Core engineering principle derived from: TotT: Partial Mocks using Forwarding Objects.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'TotT: Partial Mocks using Forwarding Objects'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Partial Mocks using Forwarding Objects"
      ],
      "donts": [
        "Violate the principle: It allows us to use the OlympicDuck's location logic instead of rewriting/simulating the logic"
      ]
    },
    {
      "id": "2009-04-survival-techniques-for-acceptance",
      "title": "Survival techniques for acceptance tests of web applications (Part 1)",
      "source_file": "best_practices/2009-04-survival-techniques-for-acceptance.md",
      "source_url": "https://testing.googleblog.com/2009/04/survival-techniques-for-acceptance.html",
      "published_date": "2009-04-28",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Acceptance tests must meet the needs of several groups, including the users and the developers.",
      "rationale": "Core engineering principle derived from: Survival techniques for acceptance tests of web applications (Part 1).",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Survival techniques for acceptance tests of web applications (Part 1)'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Survival techniques for acceptance tests of web applications (Part 1)"
      ],
      "donts": [
        "Violate the principle: Acceptance tests must meet the needs of several groups, including the users and the developers."
      ]
    },
    {
      "id": "2009-05-survival-techniques-for-web-app",
      "title": "Survival techniques for web app acceptance tests, Part 2: increasing effectiveness and utility",
      "source_file": "best_practices/2009-05-survival-techniques-for-web-app.md",
      "source_url": "https://testing.googleblog.com/2009/05/survival-techniques-for-web-app.html",
      "published_date": "2009-05-06",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Use a combination of meaningful error messages and more detailed logs to help people to tell",
      "rationale": "Core engineering principle derived from: Survival techniques for web app acceptance tests, Part 2: increasing effectiveness and utility.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Survival techniques for web app acceptance tests, Part 2: increasing effectiveness and utility'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Survival techniques for web app acceptance tests, Part 2: increasing effectiveness and utility"
      ],
      "donts": [
        "Violate the principle: Use a combination of meaningful error messages and more detailed logs to help people to tell"
      ]
    },
    {
      "id": "2009-05-web-app-acceptance-test-survival",
      "title": "Web app acceptance test survival techniques, Part 3: Musings",
      "source_file": "best_practices/2009-05-web-app-acceptance-test-survival.md",
      "source_url": "https://testing.googleblog.com/2009/05/web-app-acceptance-test-survival.html",
      "published_date": "2009-05-20",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "They should act as 'safety rails', by analogy similar to crash barriers at the sides of roads,",
      "rationale": "Core engineering principle derived from: Web app acceptance test survival techniques, Part 3: Musings.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Web app acceptance test survival techniques, Part 3: Musings'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Web app acceptance test survival techniques, Part 3: Musings"
      ],
      "donts": [
        "Violate the principle: They should act as 'safety rails', by analogy similar to crash barriers at the sides of roads,"
      ]
    },
    {
      "id": "2009-06-7-plagues-of-software-testing",
      "title": "The 7 Plagues of Software Testing",
      "source_file": "best_practices/2009-06-7-plagues-of-software-testing.md",
      "source_url": "https://testing.googleblog.com/2009/06/7-plagues-of-software-testing.html",
      "published_date": "2009-06-22",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "We must all reinvent the wheel in the privacy of our offices only to have other testers the world",
      "rationale": "Core engineering principle derived from: The 7 Plagues of Software Testing.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'The 7 Plagues of Software Testing'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in The 7 Plagues of Software Testing"
      ],
      "donts": [
        "Violate the principle: We must all reinvent the wheel in the privacy of our offices only to have other testers the world"
      ]
    },
    {
      "id": "2009-06-by-james",
      "title": "The plague of repetitiveness",
      "source_file": "best_practices/2009-06-by-james.md",
      "source_url": "https://testing.googleblog.com/2009/06/by-james.html",
      "published_date": "2009-06-24",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Testers must pay attention to their test results too and watch for automation that isn't adding",
      "rationale": "Core engineering principle derived from: The plague of repetitiveness.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'The plague of repetitiveness'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in The plague of repetitiveness"
      ],
      "donts": [
        "Violate the principle: Testers must pay attention to their test results too and watch for automation that isn't adding"
      ]
    },
    {
      "id": "2009-07-plague-of-amnesia",
      "title": "The Plague of Amnesia",
      "source_file": "best_practices/2009-07-plague-of-amnesia.md",
      "source_url": "https://testing.googleblog.com/2009/07/plague-of-amnesia.html",
      "published_date": "2009-07-13",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P2_MEDIUM",
      "summary": "Do problems that break automation get documented so the painstaking analysis to fix them doesn't",
      "rationale": "Core engineering principle derived from: The Plague of Amnesia.",
      "enforcing_prompt": "RECOMMENDED: Apply code health practice 'The Plague of Amnesia'. Maintain clear control flow, concise functions, and high readability.",
      "dos": [
        "Follow the specific architectural guidance outlined in The Plague of Amnesia"
      ],
      "donts": [
        "Violate the principle: Do problems that break automation get documented so the painstaking analysis to fix them doesn't"
      ]
    },
    {
      "id": "2009-07-plague-of-blindness",
      "title": "The Plague of Blindness",
      "source_file": "best_practices/2009-07-plague-of-blindness.md",
      "source_url": "https://testing.googleblog.com/2009/07/plague-of-blindness.html",
      "published_date": "2009-07-29",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "We're interacting with our application under test a great deal, but we must rely on other, less",
      "rationale": "Core engineering principle derived from: The Plague of Blindness.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'The Plague of Blindness'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in The Plague of Blindness"
      ],
      "donts": [
        "Violate the principle: We're interacting with our application under test a great deal, but we must rely on other, less"
      ]
    },
    {
      "id": "2009-07-plague-of-boredom",
      "title": "The Plague of Boredom",
      "source_file": "best_practices/2009-07-plague-of-boredom.md",
      "source_url": "https://testing.googleblog.com/2009/07/plague-of-boredom.html",
      "published_date": "2009-07-21",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Make sure that in your rush to perform the small tactical testing tasks you aren't dropping the",
      "rationale": "Core engineering principle derived from: The Plague of Boredom.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'The Plague of Boredom'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in The Plague of Boredom"
      ],
      "donts": [
        "Violate the principle: Make sure that in your rush to perform the small tactical testing tasks you aren't dropping the"
      ]
    },
    {
      "id": "2009-07-plague-of-homelessness",
      "title": "The Plague of Homelessness",
      "source_file": "best_practices/2009-07-plague-of-homelessness.md",
      "source_url": "https://testing.googleblog.com/2009/07/plague-of-homelessness.html",
      "published_date": "2009-07-23",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Isn't it obvious then that testers should endeavor to create such data and environmental",
      "rationale": "Core engineering principle derived from: The Plague of Homelessness.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'The Plague of Homelessness'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in The Plague of Homelessness"
      ],
      "donts": [
        "Violate the principle: Isn't it obvious then that testers should endeavor to create such data and environmental"
      ]
    },
    {
      "id": "2009-07-separation-anxiety",
      "title": "Separation anxiety?",
      "source_file": "best_practices/2009-07-separation-anxiety.md",
      "source_url": "https://testing.googleblog.com/2009/07/separation-anxiety.html",
      "published_date": "2009-07-06",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "What this means is that instead of just creating an instance of MyGuiComponent with the required",
      "rationale": "Core engineering principle derived from: Separation anxiety?.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Separation anxiety?'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Separation anxiety?"
      ],
      "donts": [
        "Violate the principle: What this means is that instead of just creating an instance of MyGuiComponent with the required"
      ]
    },
    {
      "id": "2009-07-why-are-we-embarrassed-to-admit-that-we",
      "title": "Why are we embarrassed to admit that we don't know how to write tests?",
      "source_file": "best_practices/2009-07-why-are-we-embarrassed-to-admit-that-we.md",
      "source_url": "https://testing.googleblog.com/2009/07/why-are-we-embarrassed-to-admit-that-we.html",
      "published_date": "2009-07-08",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Do you think that the developers have any incentive to change their behavior if they don't feel",
      "rationale": "Core engineering principle derived from: Why are we embarrassed to admit that we don't know how to write tests?.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Why are we embarrassed to admit that we don't know how to write tests?'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Why are we embarrassed to admit that we don't know how to write tests?"
      ],
      "donts": [
        "Violate the principle: Do you think that the developers have any incentive to change their behavior if they don't feel"
      ]
    },
    {
      "id": "2009-08-tott-testing-gwt-without-gwttest",
      "title": "TotT: Testing GWT without GwtTestCase",
      "source_file": "best_practices/2009-08-tott-testing-gwt-without-gwttest.md",
      "source_url": "https://testing.googleblog.com/2009/08/tott-testing-gwt-without-gwttest.html",
      "published_date": "2009-08-08",
      "language_scope": "java",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "GwtTestCase is good for testing UI-specific code in JavaScript.",
      "rationale": "Core engineering principle derived from: TotT: Testing GWT without GwtTestCase.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'TotT: Testing GWT without GwtTestCase'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Testing GWT without GwtTestCase"
      ],
      "donts": [
        "Violate the principle: GwtTestCase is good for testing UI-specific code in JavaScript."
      ]
    },
    {
      "id": "2009-09-checked-exceptions-i-love-you-but-you",
      "title": "Checked exceptions I love you, but you have to go",
      "source_file": "best_practices/2009-09-checked-exceptions-i-love-you-but-you.md",
      "source_url": "https://testing.googleblog.com/2009/09/checked-exceptions-i-love-you-but-you.html",
      "published_date": "2009-09-16",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P2_MEDIUM",
      "summary": "LogRuntimeException is my runtime un-checked exception which says I don't care just log it.",
      "rationale": "Core engineering principle derived from: Checked exceptions I love you, but you have to go.",
      "enforcing_prompt": "RECOMMENDED: Apply code health practice 'Checked exceptions I love you, but you have to go'. Maintain clear control flow, concise functions, and high readability.",
      "dos": [
        "Follow the specific architectural guidance outlined in Checked exceptions I love you, but you have to go"
      ],
      "donts": [
        "Violate the principle: LogRuntimeException is my runtime un-checked exception which says I don't care just log it."
      ]
    },
    {
      "id": "2009-09-it-is-not-about-writing-tests-its-about",
      "title": "It is not about writing tests, its about writing stories",
      "source_file": "best_practices/2009-09-it-is-not-about-writing-tests-its-about.md",
      "source_url": "https://testing.googleblog.com/2009/09/it-is-not-about-writing-tests-its-about.html",
      "published_date": "2009-09-02",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "the transmission should allow the output shaft to be locked, move in same direction (D) as the",
      "rationale": "Core engineering principle derived from: It is not about writing tests, its about writing stories.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'It is not about writing tests, its about writing stories'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in It is not about writing tests, its about writing stories"
      ],
      "donts": [
        "Violate the principle: the transmission should allow the output shaft to be locked, move in same direction (D) as the"
      ]
    },
    {
      "id": "2009-10-cost-of-testing",
      "title": "Cost of Testing",
      "source_file": "best_practices/2009-10-cost-of-testing.md",
      "source_url": "https://testing.googleblog.com/2009/10/cost-of-testing.html",
      "published_date": "2009-10-02",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Cognitive load is greatly reduced since I don't have to keep all of the assumptions about the",
      "rationale": "Core engineering principle derived from: Cost of Testing.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Cost of Testing'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Cost of Testing"
      ],
      "donts": [
        "Violate the principle: Cognitive load is greatly reduced since I don't have to keep all of the assumptions about the"
      ]
    },
    {
      "id": "2009-10-tott-making-perfect-matcher",
      "title": "TotT: Making a Perfect Matcher",
      "source_file": "best_practices/2009-10-tott-making-perfect-matcher.md",
      "source_url": "https://testing.googleblog.com/2009/10/tott-making-perfect-matcher.html",
      "published_date": "2009-10-05",
      "language_scope": "universal",
      "category_id": "test_design",
      "priority": "P2_MEDIUM",
      "summary": "EXPECT_THAT(new_code, AnyOf(StartsWith(\"// Tests\")), Not(ContainsRegex(\"TODO.*intern\"))));",
      "rationale": "Core engineering principle derived from: TotT: Making a Perfect Matcher.",
      "enforcing_prompt": "RECOMMENDED: Apply test design practice 'TotT: Making a Perfect Matcher'. Ensure test assertions are narrow, descriptive, and actionable.",
      "dos": [
        "Follow the specific architectural guidance outlined in TotT: Making a Perfect Matcher"
      ],
      "donts": [
        "Violate the principle: EXPECT_THAT(new_code, AnyOf(StartsWith(\"// Tests\")), Not(ContainsRegex(\"TODO.*intern\"))));"
      ]
    },
    {
      "id": "2009-11-how-to-get-started-with-tdd",
      "title": "How to get Started with TDD",
      "source_file": "best_practices/2009-11-how-to-get-started-with-tdd.md",
      "source_url": "https://testing.googleblog.com/2009/11/how-to-get-started-with-tdd.html",
      "published_date": "2009-11-17",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Adopt Test-Driven Development (Red-Green-Refactor) to drive clear interface design and high coverage.",
      "rationale": "Writing tests first forces the developer to adopt the consumer's perspective, resulting in cleaner, hard-to-misuse APIs.",
      "enforcing_prompt": "RECOMMENDED: Practice the TDD cycle: write a small failing test demonstrating desired behavior, write minimal code to pass, and refactor for cleanliness.",
      "dos": [
        "Write small failing tests before writing production implementation",
        "Refactor production code and test code cleanly once tests pass"
      ],
      "donts": [
        "Write large quantities of untestable production code before designing test fixtures"
      ]
    },
    {
      "id": "2010-08-test-driven-code-review",
      "title": "Test Driven Code Review",
      "source_file": "best_practices/2010-08-test-driven-code-review.md",
      "source_url": "https://testing.googleblog.com/2010/08/test-driven-code-review.html",
      "published_date": "2010-08-02",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "If they don't clearly state what they test, then it's less clear how the product works.",
      "rationale": "Core engineering principle derived from: Test Driven Code Review.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Test Driven Code Review'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Test Driven Code Review"
      ],
      "donts": [
        "Violate the principle: If they don't clearly state what they test, then it's less clear how the product works."
      ]
    },
    {
      "id": "2011-06-introducing-dom-snitch-our-passive-in",
      "title": "Introducing DOM Snitch, our passive in-the-browser reconnaissance tool",
      "source_file": "best_practices/2011-06-introducing-dom-snitch-our-passive-in.md",
      "source_url": "https://testing.googleblog.com/2011/06/introducing-dom-snitch-our-passive-in.html",
      "published_date": "2011-06-21",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P2_MEDIUM",
      "summary": "Real-time: Developers can observe DOM modifications as they happen inside the browser without the",
      "rationale": "Core engineering principle derived from: Introducing DOM Snitch, our passive in-the-browser reconnaissance tool.",
      "enforcing_prompt": "RECOMMENDED: Apply control flow practice 'Introducing DOM Snitch, our passive in-the-browser reconnaissance tool'. Keep control flow flat using guard clauses and early returns.",
      "dos": [
        "Follow the specific architectural guidance outlined in Introducing DOM Snitch, our passive in-the-browser reconnaissance tool"
      ],
      "donts": [
        "Violate the principle: Real-time: Developers can observe DOM modifications as they happen inside the browser without the"
      ]
    },
    {
      "id": "2011-11-rpf-googles-record-playback-framework",
      "title": "RPF: Google's Record Playback Framework",
      "source_file": "best_practices/2011-11-rpf-googles-record-playback-framework.md",
      "source_url": "https://testing.googleblog.com/2011/11/rpf-googles-record-playback-framework.html",
      "published_date": "2011-11-17",
      "language_scope": "universal",
      "category_id": "tooling_and_scripts",
      "priority": "P2_MEDIUM",
      "summary": "Common setup routines like login should be saved as modules for reuse (a crude version of this was",
      "rationale": "Core engineering principle derived from: RPF: Google's Record Playback Framework.",
      "enforcing_prompt": "RECOMMENDED: Apply tooling practice 'RPF: Google's Record Playback Framework'. Automate quality gates with deterministic linters and test suites.",
      "dos": [
        "Follow the specific architectural guidance outlined in RPF: Google's Record Playback Framework"
      ],
      "donts": [
        "Violate the principle: Common setup routines like login should be saved as modules for reuse (a crude version of this was"
      ]
    },
    {
      "id": "2012-10-hermetic-servers",
      "title": "Hermetic Servers",
      "source_file": "best_practices/2012-10-hermetic-servers.md",
      "source_url": "https://testing.googleblog.com/2012/10/hermetic-servers.html",
      "published_date": "2012-10-03",
      "language_scope": "cpp",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "Make sure those connection points which our test won't exercise have appropriate fakes or mocks",
      "rationale": "Core engineering principle derived from: Hermetic Servers.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'Hermetic Servers'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in Hermetic Servers"
      ],
      "donts": [
        "Violate the principle: Make sure those connection points which our test won't exercise have appropriate fakes or mocks"
      ]
    },
    {
      "id": "2013-08-how-google-team-tests-mobile-apps",
      "title": "How the Google+ Team Tests Mobile Apps",
      "source_file": "best_practices/2013-08-how-google-team-tests-mobile-apps.md",
      "source_url": "https://testing.googleblog.com/2013/08/how-google-team-tests-mobile-apps.html",
      "published_date": "2013-08-30",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Unit tests: These should be your first priority in either Android or iOS.",
      "rationale": "Core engineering principle derived from: How the Google+ Team Tests Mobile Apps.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'How the Google+ Team Tests Mobile Apps'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in How the Google+ Team Tests Mobile Apps"
      ],
      "donts": [
        "Violate the principle: Unit tests: These should be your first priority in either Android or iOS."
      ]
    },
    {
      "id": "2013-11-webrtc-audio-quality-testing",
      "title": "WebRTC Audio Quality Testing",
      "source_file": "best_practices/2013-11-webrtc-audio-quality-testing.md",
      "source_url": "https://testing.googleblog.com/2013/11/webrtc-audio-quality-testing.html",
      "published_date": "2013-11-08",
      "language_scope": "cpp",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Simulated networks combined with this test is a really powerful way to test our behavior under",
      "rationale": "Core engineering principle derived from: WebRTC Audio Quality Testing.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'WebRTC Audio Quality Testing'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in WebRTC Audio Quality Testing"
      ],
      "donts": [
        "Violate the principle: Simulated networks combined with this test is a really powerful way to test our behavior under"
      ]
    },
    {
      "id": "2014-02-minimizing-unreproducible-bugs",
      "title": "Minimizing Unreproducible Bugs",
      "source_file": "best_practices/2014-02-minimizing-unreproducible-bugs.md",
      "source_url": "https://testing.googleblog.com/2014/02/minimizing-unreproducible-bugs.html",
      "published_date": "2014-02-03",
      "language_scope": "universal",
      "category_id": "functions_and_data",
      "priority": "P2_MEDIUM",
      "summary": "Do not depend on data structure iteration order unless it is guaranteed.",
      "rationale": "Core engineering principle derived from: Minimizing Unreproducible Bugs.",
      "enforcing_prompt": "RECOMMENDED: Apply function and data practice 'Minimizing Unreproducible Bugs'. Optimize data lookup and isolate pure calculation functions.",
      "dos": [
        "Follow the specific architectural guidance outlined in Minimizing Unreproducible Bugs"
      ],
      "donts": [
        "Violate the principle: Do not depend on data structure iteration order unless it is guaranteed."
      ]
    },
    {
      "id": "2014-11-protractor-angular-testing-made-easy",
      "title": "Protractor: Angular testing made easy",
      "source_file": "best_practices/2014-11-protractor-angular-testing-made-easy.md",
      "source_url": "https://testing.googleblog.com/2014/11/protractor-angular-testing-made-easy.html",
      "published_date": "2014-11-30",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "You don't need to add waits or sleeps to your test.",
      "rationale": "Core engineering principle derived from: Protractor: Angular testing made easy.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Protractor: Angular testing made easy'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Protractor: Angular testing made easy"
      ],
      "donts": [
        "Violate the principle: You don't need to add waits or sleeps to your test."
      ]
    },
    {
      "id": "2015-03-android-ui-automated-testing",
      "title": "Android UI Automated Testing",
      "source_file": "best_practices/2015-03-android-ui-automated-testing.md",
      "source_url": "https://testing.googleblog.com/2015/03/android-ui-automated-testing.html",
      "published_date": "2015-03-20",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Don't write E2E tests instead of UI tests.",
      "rationale": "Core engineering principle derived from: Android UI Automated Testing.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Android UI Automated Testing'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Android UI Automated Testing"
      ],
      "donts": [
        "Violate the principle: Don't write E2E tests instead of UI tests."
      ]
    },
    {
      "id": "2015-04-just-say-no-to-more-end-to-end-tests",
      "title": "Just Say No to More End-to-End Tests",
      "source_file": "best_practices/2015-04-just-say-no-to-more-end-to-end-tests.md",
      "source_url": "https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html",
      "published_date": "2015-04-22",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Rely on fast, deterministic unit and integration tests for functional coverage; keep end-to-end tests minimal.",
      "rationale": "Excessive end-to-end tests are slow, brittle to network and UI changes, and exponentially increase CI duration.",
      "enforcing_prompt": "RECOMMENDED: Validate business logic, error paths, and boundary conditions with small, hermetic unit tests. Reserve end-to-end tests strictly for critical user journeys and smoke testing.",
      "dos": [
        "Cover all edge cases and error handling at the unit test level",
        "Limit end-to-end tests to a small set of vital user journey workflows"
      ],
      "donts": [
        "Write end-to-end tests for matrix parameter validation or minor edge cases"
      ]
    },
    {
      "id": "2015-05-multi-repository-development",
      "title": "Multi-Repository Development",
      "source_file": "best_practices/2015-05-multi-repository-development.md",
      "source_url": "https://testing.googleblog.com/2015/05/multi-repository-development.html",
      "published_date": "2015-05-15",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P2_MEDIUM",
      "summary": "Thus, our WebRTC implementation must be louder than the others since everybody knows 1.1 must be",
      "rationale": "Core engineering principle derived from: Multi-Repository Development.",
      "enforcing_prompt": "RECOMMENDED: Apply control flow practice 'Multi-Repository Development'. Keep control flow flat using guard clauses and early returns.",
      "dos": [
        "Follow the specific architectural guidance outlined in Multi-Repository Development"
      ],
      "donts": [
        "Violate the principle: Thus, our WebRTC implementation must be louder than the others since everybody knows 1.1 must be"
      ]
    },
    {
      "id": "2015-10-audio-testing-automatic-gain-control",
      "title": "Audio Testing - Automatic Gain Control",
      "source_file": "best_practices/2015-10-audio-testing-automatic-gain-control.md",
      "source_url": "https://testing.googleblog.com/2015/10/audio-testing-automatic-gain-control.html",
      "published_date": "2015-10-08",
      "language_scope": "cpp",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "Add file support to Chrome's fake audio input device, so we can play a known file.",
      "rationale": "Core engineering principle derived from: Audio Testing - Automatic Gain Control.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'Audio Testing - Automatic Gain Control'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in Audio Testing - Automatic Gain Control"
      ],
      "donts": [
        "Violate the principle: Add file support to Chrome's fake audio input device, so we can play a known file."
      ]
    },
    {
      "id": "2016-02-earlgrey-ios-functional-ui-testing",
      "title": "EarlGrey - iOS Functional UI Testing Framework",
      "source_file": "best_practices/2016-02-earlgrey-ios-functional-ui-testing.md",
      "source_url": "https://testing.googleblog.com/2016/02/earlgrey-ios-functional-ui-testing.html",
      "published_date": "2016-02-16",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Powerful built-in synchronization : Tests will automatically wait for events such as animations,",
      "rationale": "Core engineering principle derived from: EarlGrey - iOS Functional UI Testing Framework.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'EarlGrey - iOS Functional UI Testing Framework'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in EarlGrey - iOS Functional UI Testing Framework"
      ],
      "donts": [
        "Violate the principle: Powerful built-in synchronization : Tests will automatically wait for events such as animations,"
      ]
    },
    {
      "id": "2016-03-from-qa-to-engineering-productivity",
      "title": "From QA to Engineering Productivity",
      "source_file": "best_practices/2016-03-from-qa-to-engineering-productivity.md",
      "source_url": "https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html",
      "published_date": "2016-03-22",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Test Engineers (TEs) -- With their deep product knowledge and test/quality domain expertise, TEs",
      "rationale": "Core engineering principle derived from: From QA to Engineering Productivity.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'From QA to Engineering Productivity'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in From QA to Engineering Productivity"
      ],
      "donts": [
        "Violate the principle: Test Engineers (TEs) -- With their deep product knowledge and test/quality domain expertise, TEs"
      ]
    },
    {
      "id": "2016-05-flaky-tests-at-google-and-how-we",
      "title": "Flaky Tests at Google and How We Mitigate Them",
      "source_file": "best_practices/2016-05-flaky-tests-at-google-and-how-we.md",
      "source_url": "https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html",
      "published_date": "2016-05-27",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "As we analyze the data from flaky test executions, we are seeing promising correlations with",
      "rationale": "Core engineering principle derived from: Flaky Tests at Google and How We Mitigate Them.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Flaky Tests at Google and How We Mitigate Them'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Flaky Tests at Google and How We Mitigate Them"
      ],
      "donts": [
        "Violate the principle: As we analyze the data from flaky test executions, we are seeing promising correlations with"
      ]
    },
    {
      "id": "2016-06-the-inquiry-method-for-test-planning",
      "title": "The Inquiry Method for Test Planning",
      "source_file": "best_practices/2016-06-the-inquiry-method-for-test-planning.md",
      "source_url": "https://testing.googleblog.com/2016/06/the-inquiry-method-for-test-planning.html",
      "published_date": "2016-06-06",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Before a project gets too far into implementation, all scenarios must be designed as testable,",
      "rationale": "Core engineering principle derived from: The Inquiry Method for Test Planning.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'The Inquiry Method for Test Planning'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in The Inquiry Method for Test Planning"
      ],
      "donts": [
        "Violate the principle: Before a project gets too far into implementation, all scenarios must be designed as testable,"
      ]
    },
    {
      "id": "2016-09-testing-on-toilet-what-makes-good-end",
      "title": "Testing on the Toilet: What Makes a Good End-to-End Test?",
      "source_file": "best_practices/2016-09-testing-on-toilet-what-makes-good-end.md",
      "source_url": "https://testing.googleblog.com/2016/09/testing-on-toilet-what-makes-good-end.html",
      "published_date": "2016-09-21",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "For each important use case, there should be one corresponding end-to-end test.",
      "rationale": "Core engineering principle derived from: Testing on the Toilet: What Makes a Good End-to-End Test?.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Testing on the Toilet: What Makes a Good End-to-End Test?'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Testing on the Toilet: What Makes a Good End-to-End Test?"
      ],
      "donts": [
        "Violate the principle: For each important use case, there should be one corresponding end-to-end test."
      ]
    },
    {
      "id": "2016-09-what-test-engineers-do-at-google",
      "title": "What Test Engineers do at Google",
      "source_file": "best_practices/2016-09-what-test-engineers-do-at-google.md",
      "source_url": "https://testing.googleblog.com/2016/09/what-test-engineers-do-at-google.html",
      "published_date": "2016-09-12",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Write an automated test suite that validates if content presented to a user is of an acceptable",
      "rationale": "Core engineering principle derived from: What Test Engineers do at Google.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'What Test Engineers do at Google'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in What Test Engineers do at Google"
      ],
      "donts": [
        "Violate the principle: Write an automated test suite that validates if content presented to a user is of an acceptable"
      ]
    },
    {
      "id": "2016-11-hackable-projects-pillar-3",
      "title": "Hackable Projects - Pillar 3: Infrastructure",
      "source_file": "best_practices/2016-11-hackable-projects-pillar-3.md",
      "source_url": "https://testing.googleblog.com/2016/11/hackable-projects-pillar-3.html",
      "published_date": "2016-11-10",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Add more machines to your continuous build as your test set or number of developers grows.",
      "rationale": "Core engineering principle derived from: Hackable Projects - Pillar 3: Infrastructure.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Hackable Projects - Pillar 3: Infrastructure'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Hackable Projects - Pillar 3: Infrastructure"
      ],
      "donts": [
        "Violate the principle: Add more machines to your continuous build as your test set or number of developers grows."
      ]
    },
    {
      "id": "2016-11-what-test-engineers-do-at-google",
      "title": "What Test Engineers do at Google: Building Test Infrastructure",
      "source_file": "best_practices/2016-11-what-test-engineers-do-at-google.md",
      "source_url": "https://testing.googleblog.com/2016/11/what-test-engineers-do-at-google.html",
      "published_date": "2016-11-18",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "The new tests run in about 3 minutes instead of 30 minutes for the end-to-end tests.",
      "rationale": "Core engineering principle derived from: What Test Engineers do at Google: Building Test Infrastructure.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'What Test Engineers do at Google: Building Test Infrastructure'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in What Test Engineers do at Google: Building Test Infrastructure"
      ],
      "donts": [
        "Violate the principle: The new tests run in about 3 minutes instead of 30 minutes for the end-to-end tests."
      ]
    },
    {
      "id": "2017-05-gtac-2017-registration-is-open",
      "title": "GTAC 2017 - Registration is open!",
      "source_file": "best_practices/2017-05-gtac-2017-registration-is-open.md",
      "source_url": "https://testing.googleblog.com/2017/05/gtac-2017-registration-is-open.html",
      "published_date": "2017-05-15",
      "language_scope": "cpp",
      "category_id": "control_flow",
      "priority": "P2_MEDIUM",
      "summary": "May 15, 2017 - Registration opens for speakers and attendees, including applicants for the",
      "rationale": "Core engineering principle derived from: GTAC 2017 - Registration is open!.",
      "enforcing_prompt": "RECOMMENDED: Apply control flow practice 'GTAC 2017 - Registration is open!'. Keep control flow flat using guard clauses and early returns.",
      "dos": [
        "Follow the specific architectural guidance outlined in GTAC 2017 - Registration is open!"
      ],
      "donts": [
        "Violate the principle: May 15, 2017 - Registration opens for speakers and attendees, including applicants for the"
      ]
    },
    {
      "id": "2017-06-code-health-too-many-comments-on-your",
      "title": "Code Health: Too Many Comments on Your Code Reviews?",
      "source_file": "best_practices/2017-06-code-health-too-many-comments-on-your.md",
      "source_url": "https://testing.googleblog.com/2017/06/code-health-too-many-comments-on-your.html",
      "published_date": "2017-06-19",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P2_MEDIUM",
      "summary": "Make the diff easy to understand: Multiple changes at once make the code harder to review.",
      "rationale": "Core engineering principle derived from: Code Health: Too Many Comments on Your Code Reviews?.",
      "enforcing_prompt": "RECOMMENDED: Apply collaboration practice 'Code Health: Too Many Comments on Your Code Reviews?'. Provide clear context in commits, PRs, and review responses.",
      "dos": [
        "Follow the specific architectural guidance outlined in Code Health: Too Many Comments on Your Code Reviews?"
      ],
      "donts": [
        "Violate the principle: Make the diff easy to understand: Multiple changes at once make the code harder to review."
      ]
    },
    {
      "id": "2017-07-code-health-to-comment-or-not-to-comment",
      "title": "Code Health: To Comment or Not to Comment?",
      "source_file": "best_practices/2017-07-code-health-to-comment-or-not-to-comment.md",
      "source_url": "https://testing.googleblog.com/2017/07/code-health-to-comment-or-not-to-comment.html",
      "published_date": "2017-07-17",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P2_MEDIUM",
      "summary": "Reveal your intent: explain why the code does something (as opposed to what it does).",
      "rationale": "Core engineering principle derived from: Code Health: To Comment or Not to Comment?.",
      "enforcing_prompt": "RECOMMENDED: Apply code health practice 'Code Health: To Comment or Not to Comment?'. Maintain clear control flow, concise functions, and high readability.",
      "dos": [
        "Follow the specific architectural guidance outlined in Code Health: To Comment or Not to Comment?"
      ],
      "donts": [
        "Violate the principle: Reveal your intent: explain why the code does something (as opposed to what it does)."
      ]
    },
    {
      "id": "2017-09-code-health-providing-context-with",
      "title": "Code Health: Providing Context with Commit Messages and Bug Reports",
      "source_file": "best_practices/2017-09-code-health-providing-context-with.md",
      "source_url": "https://testing.googleblog.com/2017/09/code-health-providing-context-with.html",
      "published_date": "2017-09-11",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P2_MEDIUM",
      "summary": "Write the first line of the commit message so it stands alone, as tools like GitHub will display",
      "rationale": "Core engineering principle derived from: Code Health: Providing Context with Commit Messages and Bug Reports.",
      "enforcing_prompt": "RECOMMENDED: Apply collaboration practice 'Code Health: Providing Context with Commit Messages and Bug Reports'. Provide clear context in commits, PRs, and review responses.",
      "dos": [
        "Follow the specific architectural guidance outlined in Code Health: Providing Context with Commit Messages and Bug Reports"
      ],
      "donts": [
        "Violate the principle: Write the first line of the commit message so it stands alone, as tools like GitHub will display"
      ]
    },
    {
      "id": "2018-06-testing-on-toilet-keep-tests-focused",
      "title": "Testing on the Toilet: Keep Tests Focused",
      "source_file": "best_practices/2018-06-testing-on-toilet-keep-tests-focused.md",
      "source_url": "https://testing.googleblog.com/2018/06/testing-on-toilet-keep-tests-focused.html",
      "published_date": "2018-06-11",
      "language_scope": "universal",
      "category_id": "test_design",
      "priority": "P2_MEDIUM",
      "summary": "Test names clearly describe each scenario, which makes it easier to learn which scenarios exist.",
      "rationale": "Core engineering principle derived from: Testing on the Toilet: Keep Tests Focused.",
      "enforcing_prompt": "RECOMMENDED: Apply test design practice 'Testing on the Toilet: Keep Tests Focused'. Ensure test assertions are narrow, descriptive, and actionable.",
      "dos": [
        "Follow the specific architectural guidance outlined in Testing on the Toilet: Keep Tests Focused"
      ],
      "donts": [
        "Violate the principle: Test names clearly describe each scenario, which makes it easier to learn which scenarios exist."
      ]
    },
    {
      "id": "2018-11-testing-on-toilet-exercise-service-call",
      "title": "Testing on the Toilet: Exercise Service Call Contracts in Tests",
      "source_file": "best_practices/2018-11-testing-on-toilet-exercise-service-call.md",
      "source_url": "https://testing.googleblog.com/2018/11/testing-on-toilet-exercise-service-call.html",
      "published_date": "2018-11-27",
      "language_scope": "universal",
      "category_id": "test_doubles",
      "priority": "P2_MEDIUM",
      "summary": "A fake is usually maintained by the service owners; don't create your own fake unless you can",
      "rationale": "Core engineering principle derived from: Testing on the Toilet: Exercise Service Call Contracts in Tests.",
      "enforcing_prompt": "RECOMMENDED: Apply test doubles practice 'Testing on the Toilet: Exercise Service Call Contracts in Tests'. Prefer high-fidelity fakes and verify only state mutations.",
      "dos": [
        "Follow the specific architectural guidance outlined in Testing on the Toilet: Exercise Service Call Contracts in Tests"
      ],
      "donts": [
        "Violate the principle: A fake is usually maintained by the service owners; don't create your own fake unless you can"
      ]
    },
    {
      "id": "2019-11-code-health-respectful-reviews-useful",
      "title": "Code Health: Respectful Reviews == Useful Reviews",
      "source_file": "best_practices/2019-11-code-health-respectful-reviews-useful.md",
      "source_url": "https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html",
      "published_date": "2019-11-06",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P2_MEDIUM",
      "summary": "DO: Provide rationale or context, such as a best practices document, a style guide, or a design",
      "rationale": "Core engineering principle derived from: Code Health: Respectful Reviews == Useful Reviews.",
      "enforcing_prompt": "RECOMMENDED: Apply collaboration practice 'Code Health: Respectful Reviews == Useful Reviews'. Provide clear context in commits, PRs, and review responses.",
      "dos": [
        "Follow the specific architectural guidance outlined in Code Health: Respectful Reviews == Useful Reviews"
      ],
      "donts": [
        "Violate the principle: DO: Provide rationale or context, such as a best practices document, a style guide, or a design"
      ]
    },
    {
      "id": "2020-08-code-coverage-best-practices",
      "title": "Code Coverage Best Practices",
      "source_file": "best_practices/2020-08-code-coverage-best-practices.md",
      "source_url": "https://testing.googleblog.com/2020/08/code-coverage-best-practices.html",
      "published_date": "2020-08-07",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "You must treat it with the understanding that it's a lossy and indirect metric that compresses a",
      "rationale": "Core engineering principle derived from: Code Coverage Best Practices.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Code Coverage Best Practices'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Code Coverage Best Practices"
      ],
      "donts": [
        "Violate the principle: You must treat it with the understanding that it's a lossy and indirect metric that compresses a"
      ]
    },
    {
      "id": "2020-08-testing-on-toilet-avoid-hardcoding",
      "title": "Testing on the Toilet: Avoid Hardcoding Values for Better Libraries",
      "source_file": "best_practices/2020-08-testing-on-toilet-avoid-hardcoding.md",
      "source_url": "https://testing.googleblog.com/2020/08/testing-on-toilet-avoid-hardcoding.html",
      "published_date": "2020-08-19",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "If the caller doesn't need all these sizes or needs a different size, the function has to be",
      "rationale": "Core engineering principle derived from: Testing on the Toilet: Avoid Hardcoding Values for Better Libraries.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Testing on the Toilet: Avoid Hardcoding Values for Better Libraries'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Testing on the Toilet: Avoid Hardcoding Values for Better Libraries"
      ],
      "donts": [
        "Violate the principle: If the caller doesn't need all these sizes or needs a different size, the function has to be"
      ]
    },
    {
      "id": "2020-11-fixing-test-hourglass",
      "title": "Fixing a Test Hourglass",
      "source_file": "best_practices/2020-11-fixing-test-hourglass.md",
      "source_url": "https://testing.googleblog.com/2020/11/fixing-test-hourglass.html",
      "published_date": "2020-11-09",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Test Pyramid \u0026 Antipatterns, Khushi, https://khushiy.com/2019/02/07/test-pyramid-antipatterns/",
      "rationale": "Core engineering principle derived from: Fixing a Test Hourglass.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Fixing a Test Hourglass'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Fixing a Test Hourglass"
      ],
      "donts": [
        "Violate the principle: Test Pyramid \u0026 Antipatterns, Khushi, https://khushiy.com/2019/02/07/test-pyramid-antipatterns/"
      ]
    },
    {
      "id": "2021-06-how-much-testing-is-enough",
      "title": "How Much Testing is Enough?",
      "source_file": "best_practices/2021-06-how-much-testing-is-enough.md",
      "source_url": "https://testing.googleblog.com/2021/06/how-much-testing-is-enough.html",
      "published_date": "2021-06-15",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Test Flakiness - One of the Main Challenges of Automated Testing",
      "rationale": "Core engineering principle derived from: How Much Testing is Enough?.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'How Much Testing is Enough?'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in How Much Testing is Enough?"
      ],
      "donts": [
        "Violate the principle: Test Flakiness - One of the Main Challenges of Automated Testing"
      ]
    },
    {
      "id": "2022-02-code-health-now-youre-thinking-with",
      "title": "Code Health: Now You're Thinking With Functions",
      "source_file": "best_practices/2022-02-code-health-now-youre-thinking-with.md",
      "source_url": "https://testing.googleblog.com/2022/02/code-health-now-youre-thinking-with.html",
      "published_date": "2022-02-07",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P2_MEDIUM",
      "summary": "It significantly reduces duplication by abstracting away the common looping code.",
      "rationale": "Core engineering principle derived from: Code Health: Now You're Thinking With Functions.",
      "enforcing_prompt": "RECOMMENDED: Apply control flow practice 'Code Health: Now You're Thinking With Functions'. Keep control flow flat using guard clauses and early returns.",
      "dos": [
        "Follow the specific architectural guidance outlined in Code Health: Now You're Thinking With Functions"
      ],
      "donts": [
        "Violate the principle: It significantly reduces duplication by abstracting away the common looping code."
      ]
    },
    {
      "id": "2023-08-testing-on-toilet-presents",
      "title": "Better Feedback Makes for Faster Reviews",
      "source_file": "best_practices/2023-08-testing-on-toilet-presents.md",
      "source_url": "https://testing.googleblog.com/2023/08/testing-on-toilet-presents.html",
      "published_date": "2023-08-22",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Avoid statements with the word 'you' which can give the impression that you are judging the",
      "rationale": "Core engineering principle derived from: Better Feedback Makes for Faster Reviews.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Better Feedback Makes for Faster Reviews'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Better Feedback Makes for Faster Reviews"
      ],
      "donts": [
        "Violate the principle: Avoid statements with the word 'you' which can give the impression that you are judging the"
      ]
    },
    {
      "id": "2023-09-communicate-design-tradeoffs-visually",
      "title": "Communicate Design Tradeoffs Visually",
      "source_file": "best_practices/2023-09-communicate-design-tradeoffs-visually.md",
      "source_url": "https://testing.googleblog.com/2023/09/communicate-design-tradeoffs-visually.html",
      "published_date": "2023-09-21",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P2_MEDIUM",
      "summary": "This format requires the reader to remember many details in order to evaluate which option they",
      "rationale": "Core engineering principle derived from: Communicate Design Tradeoffs Visually.",
      "enforcing_prompt": "RECOMMENDED: Apply code health practice 'Communicate Design Tradeoffs Visually'. Maintain clear control flow, concise functions, and high readability.",
      "dos": [
        "Follow the specific architectural guidance outlined in Communicate Design Tradeoffs Visually"
      ],
      "donts": [
        "Violate the principle: This format requires the reader to remember many details in order to evaluate which option they"
      ]
    },
    {
      "id": "2023-09-use-abstraction-to-improve-function",
      "title": "Use Abstraction to Improve Function Readability",
      "source_file": "best_practices/2023-09-use-abstraction-to-improve-function.md",
      "source_url": "https://testing.googleblog.com/2023/09/use-abstraction-to-improve-function.html",
      "published_date": "2023-09-06",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P2_MEDIUM",
      "summary": "Avoid mixing different abstraction layers into a single function.",
      "rationale": "Core engineering principle derived from: Use Abstraction to Improve Function Readability.",
      "enforcing_prompt": "RECOMMENDED: Apply control flow practice 'Use Abstraction to Improve Function Readability'. Keep control flow flat using guard clauses and early returns.",
      "dos": [
        "Follow the specific architectural guidance outlined in Use Abstraction to Improve Function Readability"
      ],
      "donts": [
        "Violate the principle: Avoid mixing different abstraction layers into a single function."
      ]
    },
    {
      "id": "2023-10-include-only-relevant-details-in-tests",
      "title": "Include Only Relevant Details In Tests",
      "source_file": "best_practices/2023-10-include-only-relevant-details-in-tests.md",
      "source_url": "https://testing.googleblog.com/2023/10/include-only-relevant-details-in-tests.html",
      "published_date": "2023-10-30",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "A good test should include only details relevant to the test, while hiding noise:",
      "rationale": "Core engineering principle derived from: Include Only Relevant Details In Tests.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Include Only Relevant Details In Tests'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Include Only Relevant Details In Tests"
      ],
      "donts": [
        "Violate the principle: A good test should include only details relevant to the test, while hiding noise:"
      ]
    },
    {
      "id": "2023-10-shell-scripts-stay-small-simple",
      "title": "Shell Scripts: Stay Small \u0026 Simple",
      "source_file": "best_practices/2023-10-shell-scripts-stay-small-simple.md",
      "source_url": "https://testing.googleblog.com/2023/10/shell-scripts-stay-small-simple.html",
      "published_date": "2023-10-11",
      "language_scope": "shell",
      "category_id": "tooling_and_scripts",
      "priority": "P2_MEDIUM",
      "summary": "Keep shell scripts small and simple; migrate complex logic to standard compiled languages.",
      "rationale": "Large shell scripts suffer from weak error handling, lack of static type checking, and poor cross-platform portability.",
      "enforcing_prompt": "RECOMMENDED: Restrict shell scripts to simple automation pipelines under 50-100 lines. Use `set -euo pipefail`. Migrate complex logic, data transformations, and business flows to Go.",
      "dos": [
        "Use `set -euo pipefail` at the start of bash scripts",
        "Rewrite complex multi-step scripts in Go for maintainability and testing"
      ],
      "donts": [
        "Implement business logic, parsing, or complex conditionals in shell scripts"
      ]
    },
    {
      "id": "2023-10-the-secret-to-great-code-reviews",
      "title": "The Secret to Great Code Reviews: Respect Reviewers' Comments",
      "source_file": "best_practices/2023-10-the-secret-to-great-code-reviews.md",
      "source_url": "https://testing.googleblog.com/2023/10/the-secret-to-great-code-reviews.html",
      "published_date": "2023-10-04",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P2_MEDIUM",
      "summary": "You will also avoid a potentially long and emotional debate with a reviewer.",
      "rationale": "Core engineering principle derived from: The Secret to Great Code Reviews: Respect Reviewers' Comments.",
      "enforcing_prompt": "RECOMMENDED: Apply collaboration practice 'The Secret to Great Code Reviews: Respect Reviewers' Comments'. Provide clear context in commits, PRs, and review responses.",
      "dos": [
        "Follow the specific architectural guidance outlined in The Secret to Great Code Reviews: Respect Reviewers' Comments"
      ],
      "donts": [
        "Violate the principle: You will also avoid a potentially long and emotional debate with a reviewer."
      ]
    },
    {
      "id": "2023-11-clean-up-code-cruft",
      "title": "Clean Up Code Cruft",
      "source_file": "best_practices/2023-11-clean-up-code-cruft.md",
      "source_url": "https://testing.googleblog.com/2023/11/clean-up-code-cruft.html",
      "published_date": "2023-11-28",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P2_MEDIUM",
      "summary": "Apply the Boy Scout rule: leave every file cleaner and healthier than you found it.",
      "rationale": "Small, consistent cleanups prevent codebase decay and stop technical debt from accumulating over time.",
      "enforcing_prompt": "RECOMMENDED: Whenever modifying a file, perform minor cleanups: improve variable names, extract confusing expressions, and remove unused imports or dead code.",
      "dos": [
        "Clean up localized code smells in files you are already modifying",
        "Keep localized cleanups atomic and safe with existing unit test coverage"
      ],
      "donts": [
        "Ignore glaring code health issues in adjacent code while making edits"
      ]
    },
    {
      "id": "2023-11-write-clean-code-to-reduce-cognitive",
      "title": "Write Clean Code to Reduce Cognitive Load",
      "source_file": "best_practices/2023-11-write-clean-code-to-reduce-cognitive.md",
      "source_url": "https://testing.googleblog.com/2023/11/write-clean-code-to-reduce-cognitive.html",
      "published_date": "2023-11-06",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P2_MEDIUM",
      "summary": "Prefer to keep functions small, and try to limit each class to a single responsibility.",
      "rationale": "Core engineering principle derived from: Write Clean Code to Reduce Cognitive Load.",
      "enforcing_prompt": "RECOMMENDED: Apply control flow practice 'Write Clean Code to Reduce Cognitive Load'. Keep control flow flat using guard clauses and early returns.",
      "dos": [
        "Follow the specific architectural guidance outlined in Write Clean Code to Reduce Cognitive Load"
      ],
      "donts": [
        "Violate the principle: Prefer to keep functions small, and try to limit each class to a single responsibility."
      ]
    },
    {
      "id": "2023-12-exceptional-exception-handling",
      "title": "Exceptional Exception Handling",
      "source_file": "best_practices/2023-12-exceptional-exception-handling.md",
      "source_url": "https://testing.googleblog.com/2023/12/exceptional-exception-handling.html",
      "published_date": "2023-12-05",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P2_MEDIUM",
      "summary": "This means that the root cause is lost - we don't know what exactly goes wrong with pizza baking",
      "rationale": "Core engineering principle derived from: Exceptional Exception Handling.",
      "enforcing_prompt": "RECOMMENDED: Apply code health practice 'Exceptional Exception Handling'. Maintain clear control flow, concise functions, and high readability.",
      "dos": [
        "Follow the specific architectural guidance outlined in Exceptional Exception Handling"
      ],
      "donts": [
        "Violate the principle: This means that the root cause is lost - we don't know what exactly goes wrong with pizza baking"
      ]
    },
    {
      "id": "2024-03-whats-in-name",
      "title": "What's in a Name?",
      "source_file": "best_practices/2024-03-whats-in-name.md",
      "source_url": "https://testing.googleblog.com/2024/03/whats-in-name.html",
      "published_date": "2024-03-26",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P2_MEDIUM",
      "summary": "Avoid prefixes like \"handle\" or \"on\" as they describe when and provide no added meaning:",
      "rationale": "Core engineering principle derived from: What's in a Name?.",
      "enforcing_prompt": "RECOMMENDED: Apply code health practice 'What's in a Name?'. Maintain clear control flow, concise functions, and high readability.",
      "dos": [
        "Follow the specific architectural guidance outlined in What's in a Name?"
      ],
      "donts": [
        "Violate the principle: Avoid prefixes like \"handle\" or \"on\" as they describe when and provide no added meaning:"
      ]
    },
    {
      "id": "2024-04-how-i-learned-to-stop-writing-brittle",
      "title": "How I Learned To Stop Writing Brittle Tests and Love Expressive APIs",
      "source_file": "best_practices/2024-04-how-i-learned-to-stop-writing-brittle.md",
      "source_url": "https://testing.googleblog.com/2024/04/how-i-learned-to-stop-writing-brittle.html",
      "published_date": "2024-04-18",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "A valuable but challenging property for tests is \"resilience,\" meaning a test should only fail",
      "rationale": "Core engineering principle derived from: How I Learned To Stop Writing Brittle Tests and Love Expressive APIs.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'How I Learned To Stop Writing Brittle Tests and Love Expressive APIs'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in How I Learned To Stop Writing Brittle Tests and Love Expressive APIs"
      ],
      "donts": [
        "Violate the principle: A valuable but challenging property for tests is \"resilience,\" meaning a test should only fail"
      ]
    },
    {
      "id": "2024-08-less-is-more-principles-for-simple",
      "title": "Less Is More: Principles for Simple Comments",
      "source_file": "best_practices/2024-08-less-is-more-principles-for-simple.md",
      "source_url": "https://testing.googleblog.com/2024/08/less-is-more-principles-for-simple.html",
      "published_date": "2024-08-21",
      "language_scope": "universal",
      "category_id": "functions_and_data",
      "priority": "P2_MEDIUM",
      "summary": "Avoid extensive implementation details in function-level comments.",
      "rationale": "Core engineering principle derived from: Less Is More: Principles for Simple Comments.",
      "enforcing_prompt": "RECOMMENDED: Apply function and data practice 'Less Is More: Principles for Simple Comments'. Optimize data lookup and isolate pure calculation functions.",
      "dos": [
        "Follow the specific architectural guidance outlined in Less Is More: Principles for Simple Comments"
      ],
      "donts": [
        "Violate the principle: Avoid extensive implementation details in function-level comments."
      ]
    },
    {
      "id": "2024-09-write-change-resilient-code-with-domain",
      "title": "Write Change-Resilient Code With Domain Objects",
      "source_file": "best_practices/2024-09-write-change-resilient-code-with-domain.md",
      "source_url": "https://testing.googleblog.com/2024/09/write-change-resilient-code-with-domain.html",
      "published_date": "2024-09-04",
      "language_scope": "universal",
      "category_id": "design_principles",
      "priority": "P2_MEDIUM",
      "summary": "Instead of writing code to match the desired behavior for the product's requirements (\"configure",
      "rationale": "Core engineering principle derived from: Write Change-Resilient Code With Domain Objects.",
      "enforcing_prompt": "RECOMMENDED: Apply architectural principle 'Write Change-Resilient Code With Domain Objects'. Avoid premature abstractions and model clear domain boundaries.",
      "dos": [
        "Follow the specific architectural guidance outlined in Write Change-Resilient Code With Domain Objects"
      ],
      "donts": [
        "Violate the principle: Instead of writing code to match the desired behavior for the product's requirements (\"configure"
      ]
    },
    {
      "id": "2024-10-smurf-beyond-test-pyramid",
      "title": "SMURF: Beyond the Test Pyramid",
      "source_file": "best_practices/2024-10-smurf-beyond-test-pyramid.md",
      "source_url": "https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html",
      "published_date": "2024-10-15",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Balance tests across the SMURF dimensions: Speed, Maintainability, Utilization, Reliability, and Fidelity.",
      "rationale": "Focusing solely on test execution speed at the expense of fidelity produces test suites that pass while production breaks.",
      "enforcing_prompt": "RECOMMENDED: Optimize unit and integration tests across all SMURF dimensions. Strive for fast, maintainable, highly reliable tests that maintain authentic behavioral fidelity.",
      "dos": [
        "Design tests to be fast (\u003c100ms) while preserving high behavioral fidelity",
        "Use in-memory fakes to maximize speed without sacrificing reliability"
      ],
      "donts": [
        "Rely exclusively on slow end-to-end tests for basic business logic validation"
      ]
    },
    {
      "id": "2025-01-arrange-your-code-to-communicate-data",
      "title": "Arrange Your Code to Communicate Data Flow",
      "source_file": "best_practices/2025-01-arrange-your-code-to-communicate-data.md",
      "source_url": "https://testing.googleblog.com/2025/01/arrange-your-code-to-communicate-data.html",
      "published_date": "2025-01-07",
      "language_scope": "universal",
      "category_id": "control_flow",
      "priority": "P2_MEDIUM",
      "summary": "To make code easier to understand and to reduce cognitive load for your readers, make sure that",
      "rationale": "Core engineering principle derived from: Arrange Your Code to Communicate Data Flow.",
      "enforcing_prompt": "RECOMMENDED: Apply control flow practice 'Arrange Your Code to Communicate Data Flow'. Keep control flow flat using guard clauses and early returns.",
      "dos": [
        "Follow the specific architectural guidance outlined in Arrange Your Code to Communicate Data Flow"
      ],
      "donts": [
        "Violate the principle: To make code easier to understand and to reduce cognitive load for your readers, make sure that"
      ]
    },
    {
      "id": "2025-09-sort-lines-in-source-code",
      "title": "Sort Lines in Source Code",
      "source_file": "best_practices/2025-09-sort-lines-in-source-code.md",
      "source_url": "https://testing.googleblog.com/2025/09/sort-lines-in-source-code.html",
      "published_date": "2025-09-15",
      "language_scope": "universal",
      "category_id": "code_hygiene",
      "priority": "P2_MEDIUM",
      "summary": "Add keep-sorted start and keep-sorted end comments in your file, surrounding the lines you want to",
      "rationale": "Core engineering principle derived from: Sort Lines in Source Code.",
      "enforcing_prompt": "RECOMMENDED: Apply code health practice 'Sort Lines in Source Code'. Maintain clear control flow, concise functions, and high readability.",
      "dos": [
        "Follow the specific architectural guidance outlined in Sort Lines in Source Code"
      ],
      "donts": [
        "Violate the principle: Add keep-sorted start and keep-sorted end comments in your file, surrounding the lines you want to"
      ]
    },
    {
      "id": "2026-03-set-safe-defaults-for-flags",
      "title": "Set Safe Defaults for Flags",
      "source_file": "best_practices/2026-03-set-safe-defaults-for-flags.md",
      "source_url": "https://testing.googleblog.com/2026/03/set-safe-defaults-for-flags.html",
      "published_date": "2026-03-03",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P2_MEDIUM",
      "summary": "cliArgs.addBoolFlag(name=\"dry_run\", default=False, help=\"If set, print change summary, but do NOT",
      "rationale": "Core engineering principle derived from: Set Safe Defaults for Flags.",
      "enforcing_prompt": "RECOMMENDED: Apply collaboration practice 'Set Safe Defaults for Flags'. Provide clear context in commits, PRs, and review responses.",
      "dos": [
        "Follow the specific architectural guidance outlined in Set Safe Defaults for Flags"
      ],
      "donts": [
        "Violate the principle: cliArgs.addBoolFlag(name=\"dry_run\", default=False, help=\"If set, print change summary, but do NOT"
      ]
    },
    {
      "id": "2026-03-the-way-of-tdd",
      "title": "The Way of TDD",
      "source_file": "best_practices/2026-03-the-way-of-tdd.md",
      "source_url": "https://testing.googleblog.com/2026/03/the-way-of-tdd.html",
      "published_date": "2026-03-10",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Adopt Test-Driven Development (Red-Green-Refactor) to drive clear interface design and high coverage.",
      "rationale": "Writing tests first forces the developer to adopt the consumer's perspective, resulting in cleaner, hard-to-misuse APIs.",
      "enforcing_prompt": "RECOMMENDED: Practice the TDD cycle: write a small failing test demonstrating desired behavior, write minimal code to pass, and refactor for cleanliness.",
      "dos": [
        "Write small failing tests before writing production implementation",
        "Refactor production code and test code cleanly once tests pass"
      ],
      "donts": [
        "Write large quantities of untestable production code before designing test fixtures"
      ]
    },
    {
      "id": "2026-05-code-review-responses-add-context-when",
      "title": "Code Review Responses: Add Context When It Counts",
      "source_file": "best_practices/2026-05-code-review-responses-add-context-when.md",
      "source_url": "https://testing.googleblog.com/2026/05/code-review-responses-add-context-when.html",
      "published_date": "2026-05-12",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P2_MEDIUM",
      "summary": "Respond to code review feedback constructively with technical context, trade-off analysis, and clear rationale.",
      "rationale": "Thoughtful, context-rich review discussions improve code quality and maintain healthy team collaboration.",
      "enforcing_prompt": "RECOMMENDED: When responding to review comments, provide explicit rationale, constraint details, and design trade-offs. Mark non-blocking suggestions clearly as `nit:` or `optional:`.",
      "dos": [
        "Provide clear context and trade-off rationales when replying to review comments",
        "Mark minor cosmetic comments with `nit:` to unblock the author"
      ],
      "donts": [
        "Respond defensively without explaining technical reasons",
        "Reject reviewer suggestions without addressing underlying architectural concerns"
      ]
    },
    {
      "id": "2026-06-choosing-values-for-robust-tests",
      "title": "Choosing Values for Robust Tests",
      "source_file": "best_practices/2026-06-choosing-values-for-robust-tests.md",
      "source_url": "https://testing.googleblog.com/2026/06/choosing-values-for-robust-tests.html",
      "published_date": "2026-06-04",
      "language_scope": "universal",
      "category_id": "testing_strategy",
      "priority": "P2_MEDIUM",
      "summary": "Test multiple inputs that cover different scenarios, where it is reasonable to do so.",
      "rationale": "Core engineering principle derived from: Choosing Values for Robust Tests.",
      "enforcing_prompt": "RECOMMENDED: Apply testing strategy practice 'Choosing Values for Robust Tests'. Build fast, hermetic, single-process tests.",
      "dos": [
        "Follow the specific architectural guidance outlined in Choosing Values for Robust Tests"
      ],
      "donts": [
        "Violate the principle: Test multiple inputs that cover different scenarios, where it is reasonable to do so."
      ]
    },
    {
      "id": "2007-02-lifes-too-short-to-worry-about-slogans",
      "title": "Life's too short to worry about slogans",
      "source_file": "best_practices/2007-02-lifes-too-short-to-worry-about-slogans.md",
      "source_url": "https://testing.googleblog.com/2007/02/lifes-too-short-to-worry-about-slogans.html",
      "published_date": "2007-02-06",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P3_INFO",
      "summary": "Life's too short to worry about slogans",
      "rationale": "Informational article providing historical context and community updates.",
      "enforcing_prompt": "INFORMATIONAL: Reference context for 'Life's too short to worry about slogans'.",
      "dos": [
        "Review historical context if relevant to engineering culture"
      ],
      "donts": [
        "Treat informational articles as rigid blocking requirements"
      ]
    },
    {
      "id": "2007-03-robot-testers-invade-portland_15",
      "title": "Robot testers invade Portland",
      "source_file": "best_practices/2007-03-robot-testers-invade-portland_15.md",
      "source_url": "https://testing.googleblog.com/2007/03/robot-testers-invade-portland_15.html",
      "published_date": "2007-03-15",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P3_INFO",
      "summary": "Robot testers invade Portland",
      "rationale": "Informational article providing historical context and community updates.",
      "enforcing_prompt": "INFORMATIONAL: Reference context for 'Robot testers invade Portland'.",
      "dos": [
        "Review historical context if relevant to engineering culture"
      ],
      "donts": [
        "Treat informational articles as rigid blocking requirements"
      ]
    },
    {
      "id": "2007-04-test-engineering-internships",
      "title": "Test Engineering Internships",
      "source_file": "best_practices/2007-04-test-engineering-internships.md",
      "source_url": "https://testing.googleblog.com/2007/04/test-engineering-internships.html",
      "published_date": "2007-04-16",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P3_INFO",
      "summary": "Test Engineering Internships",
      "rationale": "Informational article providing historical context and community updates.",
      "enforcing_prompt": "INFORMATIONAL: Reference context for 'Test Engineering Internships'.",
      "dos": [
        "Review historical context if relevant to engineering culture"
      ],
      "donts": [
        "Treat informational articles as rigid blocking requirements"
      ]
    },
    {
      "id": "2009-06-gtac-call-for-proposals",
      "title": "GTAC: Call for Proposals",
      "source_file": "best_practices/2009-06-gtac-call-for-proposals.md",
      "source_url": "https://testing.googleblog.com/2009/06/gtac-call-for-proposals.html",
      "published_date": "2009-06-17",
      "language_scope": "cpp",
      "category_id": "collaboration_and_reviews",
      "priority": "P3_INFO",
      "summary": "GTAC: Call for Proposals",
      "rationale": "Informational article providing historical context and community updates.",
      "enforcing_prompt": "INFORMATIONAL: Reference context for 'GTAC: Call for Proposals'.",
      "dos": [
        "Review historical context if relevant to engineering culture"
      ],
      "donts": [
        "Treat informational articles as rigid blocking requirements"
      ]
    },
    {
      "id": "2009-07-blog-stats",
      "title": "Blog Stats",
      "source_file": "best_practices/2009-07-blog-stats.md",
      "source_url": "https://testing.googleblog.com/2009/07/blog-stats.html",
      "published_date": "2009-07-21",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P3_INFO",
      "summary": "Blog Stats",
      "rationale": "Informational article providing historical context and community updates.",
      "enforcing_prompt": "INFORMATIONAL: Reference context for 'Blog Stats'.",
      "dos": [
        "Review historical context if relevant to engineering culture"
      ],
      "donts": [
        "Treat informational articles as rigid blocking requirements"
      ]
    },
    {
      "id": "2009-07-call-for-attendance-google-test",
      "title": "Call for Attendance: Google Test Automation Conference (GTAC) 2009",
      "source_file": "best_practices/2009-07-call-for-attendance-google-test.md",
      "source_url": "https://testing.googleblog.com/2009/07/call-for-attendance-google-test.html",
      "published_date": "2009-07-29",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P3_INFO",
      "summary": "Call for Attendance: Google Test Automation Conference (GTAC) 2009",
      "rationale": "Informational article providing historical context and community updates.",
      "enforcing_prompt": "INFORMATIONAL: Reference context for 'Call for Attendance: Google Test Automation Conference (GTAC) 2009'.",
      "dos": [
        "Review historical context if relevant to engineering culture"
      ],
      "donts": [
        "Treat informational articles as rigid blocking requirements"
      ]
    },
    {
      "id": "2010-03-google-is-hiring-sets",
      "title": "Google is hiring SETs",
      "source_file": "best_practices/2010-03-google-is-hiring-sets.md",
      "source_url": "https://testing.googleblog.com/2010/03/google-is-hiring-sets.html",
      "published_date": "2010-03-12",
      "language_scope": "universal",
      "category_id": "collaboration_and_reviews",
      "priority": "P3_INFO",
      "summary": "Google is hiring SETs",
      "rationale": "Informational article providing historical context and community updates.",
      "enforcing_prompt": "INFORMATIONAL: Reference context for 'Google is hiring SETs'.",
      "dos": [
        "Review historical context if relevant to engineering culture"
      ],
      "donts": [
        "Treat informational articles as rigid blocking requirements"
      ]
    }
  ]
}