Balder is an open-source Python test framework for embedded systems and product variants, emphasizing reusable test logic decoupled from implementation. It supports plugin-based architecture, J-Unit reporting, and reusable packages for tasks like browser automation and API testing.

Richard Seidl Software Testing

This is the other podcast on Software Testing by Richard Seidl, the episodes are in spoken German but the show notes and site are written in English. Our summaries are generated from AI transcript translations.

• https://www.richard-seidl.com/en/blog/tag/podcast-software-testing
• https://www.richard-seidl.com/en/

Episode Details

• Show Notes: https://www.richard-seidl.com/de/podcast/python-testframework-produktvarianten
• Published: 2026-10-27T05:00:00Z
• Duration: 00:19:53
• Author: Richard Seidl - Experte fur Software-Entwicklung und Testautomatisierung

Overview

The podcast discusses Balder, an open-source test framework designed for flexibility and reusability in testing, particularly within embedded systems and product variants. A core principle of Balder is the separation of test logic from implementation, allowing tests to be defined abstractly without being tied to specific technologies or devices. This enables the same test scenarios to be reused across different configurations - such as heart rate monitors using either electrical or optical sensors - by only adapting the implementation layer, like simulation methods, while keeping the underlying test logic intact.

The framework is built in Python from the ground up, avoiding external dependencies like PyTest to allow greater control and automatic matching between abstract test scenarios and their concrete setups. It supports a plugin-based architecture with features like J-Unit reporting and MIT licensing to encourage community contributions. Pre-built packages, known as Valter Hub packages, offer reusable components for tasks such as Selenium-based browser automation, REST API testing, and data model validation. These tools simplify test creation for both embedded and web applications, with future plans including expanded hardware integration and support for additional web frameworks.

What If

• What if you restructured your test suite to separate logic from implementation like Balder?

  • Move: Refactor one core test module in your current project to define abstract test scenarios (e.g., “user login succeeds”) while decoupling the execution steps (e.g., Selenium vs. API calls). Store these as plain Python classes or YAML configs.
  • Why Now?: If you’re manually rewriting tests across product variants or tech stacks, you’re wasting time - just like embedded teams replacing optical sensors with electrical ones. The pain is already real and growing.
  • Expected Upside: Reuse 80%+ of test logic when switching frontends, APIs, or device types. Cut test maintenance by 50% over six months as changes only require updating implementation layers, not rewriting entire suites.

• What if you published a reusable test package for your most common workflow?

  • Move: Package a high-value test flow (e.g., “CRUD user via REST + UI validation”) into a standalone, MIT-licensed Python module with minimal dependencies. Publish it on GitHub and PyPI, modeled after Valter Hub packages.
  • Why Now?: If others in your niche are reinventing the same tests (e.g., Django admin validations), you can lead the ecosystem - and reduce your own workload by getting community fixes.
  • Expected Upside: Gain inbound traffic, user feedback, and contributions that improve your own test reliability. Future projects can install your package and skip days of setup.

• What if you automated test-to-device matching using configuration instead of code?

  • Move: Build a simple matcher that reads test requirements (e.g., “needs BLE support”) and auto-selects available hardware setups (e.g., “Raspberry Pi + BLE dongle”) from a config file - just like Balder’s scenario-to-setup binding.
  • Why Now?: If you’re manually assigning tests to devices or environments, you’re creating a bottleneck. Embedded and web teams alike face this as product variants grow.
  • Expected Upside: Run the same test battery across multiple device configurations without code changes. Achieve 3x faster test deployment when adding new hardware variants or staging environments.

Takeaway

• Design test cases using abstract scenarios that separate test logic from implementation, enabling reuse across different hardware or software configurations.
• Build or adopt a plugin-based, dependency-light test framework (e.g., Python-based) to maintain control and flexibility for embedded or variant-heavy systems.
• Create reusable test packages (e.g., for CRUD operations or protocol handling) that can be shared across projects or published to a central hub for team or community reuse.
• When protocols or interfaces change, isolate and update only the implementation layer (e.g., simulation method) while preserving the core test logic to reduce maintenance effort.
• Contribute to or leverage open-source test automation projects (e.g., Balder on GitHub) to accelerate development and integrate pre-built solutions for common testing challenges.