Windows Python Setup Step 60 is Integration testing: produce a isolated multi-component test boundary that can be rebuilt, reviewed, tested, and operated from the verified Windows project established in Steps 1–7. This milestone adds one bounded capability. It does not replace interpreter ownership, the project .venv, dependency declarations, the Step 6 quality gate, or the Step 7 clean Windows CI matrix.

The working contract is specific: real adapters cooperate with controlled dependencies. The main failure to design against is calling shared production services from CI. Treat those as acceptance and risk statements, not optional commentary.

Resume from the proven project

Open a fresh PowerShell window at the repository root:

Set-Location "$HOME\Projects\hello-python"
.\.venv\Scripts\Activate.ps1
python -c "import sys; print(sys.executable)"
python -m pip check
python .\quality_gate.py
git status --short

The executable must end in the project .venv\Scripts\python.exe, not a global runtime or pythonw.exe. Every python -c example in this guide is one physical line; do not insert a PowerShell continuation backtick between -c and its quoted program.

Stop if the existing gate fails or the working tree contains unexplained changes. Step 60 should create a reviewable delta from a known baseline. Record unrelated work rather than sweeping it into this milestone.

Define the Step 60 boundary

The deliverable is isolated multi-component test boundary. Write down its caller, inputs, outputs, error semantics, resource ownership, and observable result before selecting a library. A tool name is not an architecture. The boundary should remain testable when Windows paths contain spaces, the working directory changes, the network is unavailable, or an optional dependency is missing.

Create the smallest module or configuration file that owns Integration testing. Keep domain policy separate from adapters that touch the filesystem, process environment, network, database, GUI, operating system, or external service. Pure policy can be tested quickly; adapters need explicit integration tests and cleanup.

Do not hard-code C:\Users\Danny Li, a drive letter, a personal checkout, or a .venv executable. Derive project resources with pathlib, accept deployment locations through validated configuration, and keep user-specific state outside source control.

Inspect before adding dependencies

Search the project for an existing owner:

Get-ChildItem -Recurse -File | Select-String -SimpleMatch "Integration testing"
git ls-files

If the repository already has a framework, configuration section, adapter, test helper, or operational policy for this subject, extend that source of truth. Do not create parallel logging systems, HTTP clients, database sessions, configuration loaders, test runners, packaging metadata, or release scripts.

Prefer the standard library when it satisfies the contract. When a third-party distribution is justified, verify its official project identity, supported Python versions, license, maintenance posture, release notes, and transitive dependencies. Install it only through the selected interpreter and add it to the project's established dependency source.

python -m pip check
python -m pip freeze

pip freeze is evidence of the current environment, not permission to replace a reviewed lock or dependency declaration. Never copy package versions blindly from this article; resolve according to project policy and test the resulting set on every supported Python version.

Implement one vertical slice

Build a thin end-to-end slice: accept one valid input, execute the Integration testing policy, return or persist the intended output, and expose one useful diagnostic. Keep side effects behind a narrow function/class so tests can substitute a controlled adapter.

Use explicit names and types. Validate at trust boundaries rather than deep inside business logic. Return stable domain results or raise a small documented exception family; do not leak raw library exceptions through every layer. Preserve causal context with exception chaining when translation is necessary.

The primary Step 60 exercise command is:

python -m pytest -m integration

Run it from the project root through the verified interpreter/tool owner. If it is a diagnostic command, capture only non-sensitive facts. If it starts a service or GUI, use a development-only binding and stop it cleanly after the smoke check. If it invokes a test, make the test independent of live production services.

Model inputs and outputs explicitly

Document required versus optional fields, accepted ranges, encoding, path rules, time-zone expectations, and maximum sizes. Reject ambiguous or malformed data with an actionable message. Defaults should be safe, visible, and stable; an absent critical setting must not silently select a dangerous behavior.

Machine-readable output needs a versioned schema or compatibility policy. Human-readable output should separate normal results on stdout from diagnostics on stderr and use meaningful exit codes. Do not parse localized display text as an internal interface.

For files, write to a temporary sibling and atomically replace where the filesystem supports it. For databases, define transaction ownership. For network work, set connect/read/total time budgets. For processes, pass argument lists rather than shell-built strings. For concurrency, define cancellation and shutdown before starting workers.

Test behavior and failure

Add tests beside the established suite. Cover one normal example, a meaningful boundary, malformed input, an unavailable dependency, and cleanup after an injected failure. Assert public results and durable side effects rather than private call order.

Use temporary directories and temporary databases. Use fakes at remote boundaries for fast deterministic tests, then add a smaller integration test that proves the real adapter contract. Never point automated tests at a shared production account, personal directory, mapped drive, or mutable external resource.

Run focused tests first, then the full gate:

python -m pytest -q
python .\quality_gate.py

A passing happy path is insufficient. Deliberately violate one invariant and confirm the test fails for the intended reason; restore it and rerun. This negative proof catches skipped tests, incorrect discovery, swallowed exit codes, and assertions that never execute.

Windows-specific qualification

Exercise paths containing spaces and non-ASCII characters. Do not assume a case-sensitive filesystem, POSIX separators, executable permission bits, fork, Bash syntax, or a visible interactive desktop. Services and scheduled tasks often have different profiles, environment variables, network-drive mappings, certificate stores, and working directories than the developer terminal.

Open files with explicit text encoding and appropriate newline behavior. Close handles deterministically so Windows can rename or delete temporary files. Bound retry behavior around transient sharing violations; never turn an access-denied or persistent lock into an infinite loop.

If the feature crosses PowerShell, cmd.exe, WSL, COM, Task Scheduler, a Windows service, or a container boundary, document which parser and identity owns every argument. Test exit-code propagation. Avoid shell=True and string-built commands when an argument array or direct API exists.

Security and privacy review

Apply least privilege to files, tokens, workflow permissions, network listeners, database roles, and service accounts. Keep secrets out of command lines, URLs, repository files, exceptions, screenshots, test fixtures, and logs. Redact by field policy rather than after arbitrary strings have already been emitted.

Treat external files, archives, JSON, CSV, HTTP responses, package artifacts, environment variables, registry values, queue messages, and user input as untrusted. Validate size before allocation, normalize only after defining semantics, and reject traversal or unexpected destinations. Never disable TLS verification, ACLs, authentication, or safety checks merely to make a tutorial command pass.

The Step 60 threat review must directly address calling shared production services from CI. Record the chosen control and a test or operational check that proves it. If the control needs new credentials, infrastructure, administrator rights, or external coordination, stop and obtain that authority rather than hiding the dependency.

CI parity

Commit the implementation, configuration, tests, and dependency changes—never the .venv or tool caches. Step 7 should rebuild them on clean Windows runners and invoke the same quality_gate.py used locally.

git status --short
git diff
python .\quality_gate.py

Do not add a second CI-only policy that disagrees with local commands. A cache hit may improve speed but must not provide undeclared correctness. The job must still install declarations, run pip check, and execute the gate.

When the capability requires slow integration or end-to-end tests, mark and schedule them deliberately while keeping a fast pull-request signal. A required check must not silently skip the only test that proves this milestone.

Observability and operations

Define what an operator can observe without attaching a debugger: success count, bounded latency, failure category, dependency health, queue depth, last completed operation, or another signal appropriate to Integration testing. Use stable structured fields and correlation identifiers where requests cross components.

Do not log entire payloads by default. Bound log size, metric cardinality, artifact retention, and diagnostic collection. Health checks should distinguish process liveness from readiness to serve; a running process with an unavailable required dependency is not necessarily ready.

Write the recovery action beside the signal. An alert without an owner or safe response is noise. Test alert conditions and diagnostic redaction just like application behavior.

Rollout and rollback

Introduce the capability behind a narrow configuration switch or reversible integration point when risk justifies it. Establish the baseline, deploy to the smallest representative scope, observe the acceptance signal, and expand only after the result is understood.

Rollback must name the prior artifact/configuration, compatibility constraints, data consequences, and verification command. Code rollback may not reverse a schema migration, emitted message, encrypted value, external side effect, or overwritten file. Design forward repair when reversal is unsafe.

Record who owns the feature after merge, how dependencies are updated, what evidence is retained, and when the policy is reviewed. Setup is not complete when a command runs once; it is complete when another person can reproduce, diagnose, and safely retire it.

Troubleshooting without destructive shortcuts

The command is not found. Recheck sys.executable, use python -m ..., and verify the dependency declaration. Do not install globally or use --user to mask a project problem.

It works only from VS Code. Compare selected interpreter, working directory, environment, launch configuration, and unsaved files. The project command and CI gate remain authoritative.

It works only on the developer machine. Search for undeclared packages, absolute paths, user-site imports, cached state, credentials, mapped drives, locale assumptions, and interactive prompts. Reproduce on the clean Windows matrix.

Tests hang. Add timeouts at the real blocking boundary; inspect threads, child processes, sockets, UI loops, locks, and teardown. Do not add arbitrary sleeps as synchronization.

Access is denied. Identify the exact path/object and effective identity, inspect ownership/ACLs, and grant the minimum required access. Do not run the entire application as Administrator.

A test is flaky. Capture seed, timing, ordering, concurrency, locale, and external-state evidence. Make the dependency controllable instead of rerunning until green.

CI differs from local. Compare recorded Python version, dependency resolution, configuration sources, path casing, line endings, and collected tests. Preserve the failing log before changing state.

What not to do in Step 60

• Do not bypass Steps 1–7 interpreter, dependency, quality, or CI evidence.
• Do not hard-code personal Windows paths, tokens, hosts, or credentials.
• Do not create a duplicate framework or configuration source.
• Do not rely on current working directory, global packages, or user-site imports.
• Do not make live production services part of unit tests.
• Do not swallow exceptions or convert every failure to a successful exit.
• Do not disable validation, TLS, authentication, ACLs, or safety checks.
• Do not commit virtual environments, caches, generated secrets, or private data.
• Do not apply automatic fixes without reviewing the source diff.
• Do not call the milestone complete until a deliberate failure is detected.