Collections, String, DateTime, OperatingSystem, Process, and XML Libraries: Configuration, Design Patterns, and Trade-Offs

1. Decision model: use the narrowest explicit capability

Standard libraries are strongest when the operation maps cleanly to their domain: list manipulation, text conversion, date arithmetic, filesystem operations, child execution, or XML queries. Move logic into a custom Python library when the domain rule becomes complex enough that Robot syntax starts describing implementation rather than intent.

2. Standard library keyword versus custom Python library

3. OperatingSystem Run-style commands versus Process

OperatingSystem.Run, Run And Return RC, and Run And Return RC And Output are deprecated. New suites should use Process. Process accepts command and arguments separately, gives a result object, supports timeouts/background execution/termination, and lets stdout/stderr be configured independently.

4. In-memory mutation versus copied data

Collections contains both querying and mutating operations. Mutation is efficient and readable when one keyword clearly owns the object. It becomes risky when the same list/dictionary is shared through suite/global scope or passed to parallel workers. Use Copy List/Copy Dictionary at ownership boundaries; use deepcopy=True only when nested mutable items must also be independent.

5. Absolute versus relative paths

Relative paths improve portability only when their base is explicit. Robot automatic variables such as ${CURDIR}, ${EXECDIR}, ${OUTPUT DIR}, and ${TEMPDIR} communicate different ownership. For scratch data, ${TEMPDIR} plus a run-unique suffix is appropriate. For committed fixtures, ${CURDIR} is often appropriate. Do not depend on an accidental current working directory.

6. Text versus bytes and explicit encoding

Robot Framework 7.4 substantially expanded bytes support in String and standard type conversion. That does not mean bytes and text are interchangeable. Decode bytes at a known boundary using the correct encoding; encode text only when a byte-oriented protocol/file requires it. Avoid errors=ignore as a default because silently dropping data can hide corruption.

*** Settings ***
Library    String

*** Test Cases ***
Explicit Encoding Boundary
    ${bytes}=    Encode String To Bytes    café    UTF-8
    ${text}=     Decode Bytes To String    ${bytes}    UTF-8
    Should Be Equal    ${text}    café

7. Local time versus explicit timestamps

Use LOCAL when the requirement is explicitly local-human time. Use UTC for cross-host evidence and machine correlation, and include the convention in the serialized value. DateTime returns naive Python datetime objects when result_format=datetime, so do not infer timezone awareness merely because the source was UTC. For durable interchange, serialize an unambiguous timestamp.

8. XML library versus raw string matching

9. Secret-aware arguments are masking boundaries, not vaults

Robot Framework 7.4 added Secret support to relevant standard-library arguments, including file/environment/process-related values. This helps keep supported values out of normal logs. It does not encrypt files, environment variables, child-process memory, or operating-system process state. Secret creation/storage belongs to a secret-management boundary; standard libraries only consume the values safely where supported.

10. Worked scenario: choose the boundary

11. Knowledge check

12. Summary and next step

The strongest standard-library design keeps capability boundaries explicit and state ownership narrow. Lesson 4 now applies those choices to realistic failures: injection, deletion mistakes, leaked processes, output/encoding trouble, cross-platform path errors, shared mutable state, and brittle XML comparisons.

Further reading

• Robot Framework 7.4.2 Collections — list/dictionary mutation, copying, comparison, and current type-conversion behavior.
• Robot Framework 7.4.2 String — text/bytes transformation and encoding-related keywords.
• Robot Framework 7.4.2 DateTime — timestamps, time intervals, conversion, LOCAL/UTC handling, and result formats.
• Robot Framework 7.4.2 OperatingSystem — portable file/directory/environment operations and deprecated process-running keywords.
• Robot Framework 7.4.2 Process — structured process invocation, result objects, output redirection, timeouts, and cleanup.
• Robot Framework 7.4.2 XML — parsing, XPath-style element lookup, verification, mutation, and explicit save semantics.
• Robot Framework 7.4.2 release — stable release baseline used in these lessons.