Database, SSH, Filesystem, Process, and Infrastructure Automation Patterns: Configuration, Design Patterns, and Trade-Offs

1. Design frame: minimize the number of mutable states a test owns

A test that opens a database connection, edits three files, starts a daemon, SSHes to a host, and then calls an API may be “end to end,” but it has five independent cleanup contracts. That increases diagnostic ambiguity. Prefer the smallest set of boundaries that can prove the intended behavior.

2. Direct database assertion versus API assertion

A useful rule: if the requirement says “the client receives X,” assert through the service. If the requirement says “migration/index/persistence contains X,” a direct database assertion can be appropriate. Do not use DB writes to bypass the exact business behavior you are testing unless the write is explicitly fixture setup outside the behavior under test.

3. Transaction rollback versus explicit cleanup

Rollback is ideal when all mutations stay inside one connection/transaction and the test can guarantee the transaction is never committed by the code under test. Explicit cleanup is needed when state crosses transaction boundaries or is visible to another process/service. The two strategies can coexist, but their ownership must be obvious.

4. SSH remote command versus local Process

If the target is the same machine that runs Robot, use Process for a local program. Adding SSH to localhost adds authentication, host trust, port, daemon, and connection-state failure modes without changing the target. Use SSH only when remote execution is part of the integration boundary.

For a disposable remote fixture, expose a narrow domain keyword such as Read Remote Service State, not arbitrary Execute Command calls in every test. This is where an allowlist can reject package managers, service stop/start, user management, broad deletion, or shell metacharacters.

5. One domain resource versus library keywords everywhere

*** Keywords ***
Inventory Should Contain Ready Item
    [Arguments]    ${name}
    ${rows}=    Get Inventory Row    ${name}
    Length Should Be    ${rows}    1
    Should Be Equal    ${rows}[0][state]    ready

The higher-level keyword owns the data-access pattern and diagnostic message. A test now says what infrastructure condition matters instead of repeating connection aliases, SQL placeholders, and row-shape assumptions. Keep resources cohesive: one giant Common.resource containing every infrastructure operation creates dependency tangles and name collisions.

6. Persistent connection versus per-test isolation

Library scope and connection scope are different. DatabaseLibrary may be GLOBAL as a Robot library while it manages several independently aliased DB connections. SSHLibrary also maintains a global connection cache. Design the connection lifetime explicitly instead of inferring it from import placement.

7. Simulation versus real local service

Simulation is appropriate when the learning goal is Robot architecture, cleanup, and evidence—not protocol conformance. A real local service is appropriate when the behavior under test includes the protocol. The mandatory chapter uses real SQLite/filesystem/process boundaries and simulates SSH because safe SSH host-trust provisioning would otherwise dominate the lesson.

8. Absolute/owned paths versus working-directory folklore

Resolve run-owned paths once from ${OUTPUTDIR} or ${CURDIR} depending on ownership, normalize them, and pass explicit paths to libraries. Do not assume the CI working directory equals your laptop working directory. A child process can also have its own cwd; that state is distinct from Robot's ${EXECDIR}.

9. Parallelism and worker isolation

Pabot arrives later in Chapter 24, but infrastructure design must already be concurrency-safe. A fixed SQLite path such as /tmp/test.db, fixed SSH temp filename, or common process port becomes a shared resource when workers run concurrently. Use worker-specific/run-specific roots and never rely on global mutable test variables to coordinate external state.

10. “localhost” changes meaning across container boundaries

On a developer machine, 127.0.0.1 refers to that host. Inside a container, it refers to the container itself. A database or SSH service on the host is not automatically at the container's localhost. Treat network namespace, published port, DNS name, and trust material as explicit container/CI configuration. Do not rewrite a failing target to a public hostname just to make the test connect.

11. Worked decision table

12. Configuration boundaries

• Robot core: variables, suites, selection, output directory, lifecycle.
• External libraries: DatabaseLibrary/SSHLibrary import args and connection APIs.
• Python environment: database drivers, Paramiko/SCP dependencies, interpreter.
• SUT/infrastructure: DB schema, SSH daemon, users, host keys, process executables.
• Editor/RobotCode: developer assistance only; not runtime target configuration.
• CI/container: workspace, network namespace, service containers, secret injection, artifact retention.

Knowledge check

13. Summary and next lesson

Good infrastructure tests choose one boundary for a reason, minimize owned state, and isolate connection/transaction/process/path lifecycles. Lesson 4 deliberately breaks those contracts and diagnoses the evidence without using destructive shortcuts.

References and version anchors

• Robot Framework 7.4.2 User Guide, Process 7.4.2, and OperatingSystem 7.4.2 — core execution, variables/lifecycle, structured child processes, filesystem operations, and current standard-library semantics.
• DatabaseLibrary 2.4.1 keyword documentation, PyPI release, and maintainer repository — connection, query, transaction wrapper, parameter, retry, alias, and SQLite guidance.
• SSHLibrary keyword documentation, SSHLibrary 3.8.0 on PyPI, and maintainer repository — connection/session behavior and current release status. The mandatory lab does not rely on a real SSH server.
• Python sqlite3 documentation — SQLite connection/transaction behavior used by the local database fixture.