Designing the Core: What Makes a Test Node in a Modern Automation Platform?
In Part 1 I laid out the motivations for building a new kind of test automation platform—one centered around visual workflows, reusable logic, and dynamic execution. It was about creating a tool that adapts to how real-world testing actually works, not the other way around.
Now it’s time to go deeper.
This post focuses on one of the core architectural components of the platform: the Test Node. I’ll break down the shared logic that every node type follows, the initial set of nodes I’m building, and why technologies like Redis, MongoDB, and Playwright were chosen as foundational pieces.
🧱 What is a Test Node?
A Test Node represents a single step in a larger test flow. It could be anything from sending an HTTP request, performing a browser action, pausing for manual review, or calling another system.
Each node:
• Encapsulates a single, reusable piece of test logic
• Can run conditionally or in parallel with others
• Passes data along the test flow
• Emits status, logs, and results that the platform can observe
Think of it like a programmable Lego brick for building tests.
🔁 Common Features Shared Across All Nodes
To make the system composable and extendable, every node implements a common interface with the following capabilities:
🔧 Pre-Run & Post-Run Scripts
Each node can run scripts before and after its main execution. This allows dynamic logic such as:
• Modifying input values based on test context
• Injecting authentication tokens
• Parsing or transforming outputs
• Cleaning up resources post-execution
Scripts are written in JavaScript, with potential support for Python in a sandboxed runtime.
🧠 Context: Key-Value Parameters That Flow
Nodes can read from and write to a shared test context—a key-value store that flows through the test graph.
Use cases:
• Passing a record ID returned by one node into the next
• Storing flags and environment-specific data
• Dynamically modifying behaviour based on earlier node results
This gives the test flow memory and flexibility, without needing a backend in the middle.
📦 Storing Node State & Structure
Test flows aren’t just logic—they’re data. So how do we store it all?
⚡ Redis: Fast Runtime State Storage
Redis is used as a real-time buffer for node execution. It handles:
• Current node status (running, passed, failed)
• Response payloads and logs
• Temporary variable storage
• Visual trace data for the execution viewer
Why Redis? It’s fast, simple, and fits the in-memory nature of transient test runs perfectly.
🗂️ MongoDB: Flexible Storage for Node Definitions
The nodes themselves—their structure, config, scripts, and metadata—are stored in MongoDB. Here’s why:
• Schema-less by design: Different node types have different fields (e.g., httpNode has method/URL, manualNode has instructions), and Mongo doesn’t care.
• Easy versioning: Nodes evolve over time. Mongo lets us store multiple versions without migrations.
• Nested data-friendly: Node configurations often contain embedded objects (headers, conditions, scripts), which fit naturally into documents.
🧰 Initial Node Palette: The MVP Core
These are the first four nodes being implemented — the absolute essentials to get a usable test flow engine up and running:
🟢 startNode
The entry point of every test. Can be triggered:
• Manually from the UI
• On a schedule
• From external systems (e.g., CI/CD pipelines via webhooks)
It initializes the test context and kicks off execution.
🌐 httpNode
Executes RESTful API requests. Features:
• Method, URL, headers, payload
• Dynamic templating with context variables
• Assertions on status codes and response body
• Response saved to context for downstream nodes
This node forms the backbone of API test flows.
🧍♂️ manualNode
Handles human-in-the-loop steps—like verifying an email in a real inbox or confirming a UI element that can’t be reliably automated yet.
• Pauses execution
• Notifies the user/team
• Waits for manual approval or input
Sometimes, testing needs to stop and ask, “Hey, does this look right?” This node handles that.
🧪 playWrightNode
Executes browser automation scripts using Playwright.
Why Playwright?
• ✅ Multi-browser support (Chromium, Firefox, WebKit)
• ✅ Great APIs for dynamic UIs, popups, and iframes
• ✅ Headless and headed mode
• ✅ Built-in screenshot, video, and trace recording
• ✅ Strong parallel execution support
For a platform that aims to be visual and traceable, Playwright hits the sweet spot between power and simplicity.
🧭 What’s Next?
In the next post, I’ll cover how tests are modelled visually in the platform:
• How nodes are rendered
• How users build flows with drag-and-drop tools
• How live execution tracing is implemented
• And how debugging feels more like browsing a flowchart than reading logs
It’ll be hands-on with early prototypes and ReactFlow magic.
If you enjoyed this post or have feedback on the architecture, feel free to hit me up or drop a comment. This is very much a work in progress—and I’m building it in the open.
