Architecting for Testability and Observability

Описание: When systems grow, testing and observability often become afterthoughts — expensive to retrofit and harder to enforce. What if we could build them in from the very first line of LabVIEW code?

In this talk, I will start at the most granular level: small, beginner-friendly LabVIEW units. Rather than staying academic, let’s dive straight into the real-world challenges: how the LabVIEW community often struggles with adopting object-oriented programming, and how to tackle this obstacle by adapting a practical mindset that helps to overcome initial hurdles and encourages natural, experience-driven learning.

Starting with a simple example, we build unit tests around standalone components, such as simulating the behaviour of a digital multimeter (DMM). By examining multiple DMMs, we extract common functionality and design an abstraction layer, creating a flexible interface to unify varying implementations. This naturally leads us to wrapping these behaviours inside DQMH modules.

As systems scale, the need to handle multiple instances — like managing several DMMs simultaneously — becomes pressing. We address this by introducing a routing patterns within a DQMH module, allowing dynamic routing of requests to the correct device. Requests carry both a command and a device identifier, ensuring that modules stay stateless and interactions remain clean.

Next, we tackle inter-module communication. Inspired by the actor model, we treat modules as autonomous actors: you can ask them to perform tasks, but you never share internal state. Data is transmitted via immutable copies. While the naive solution would be direct peer-to-peer messaging among all modules, experience teaches us this leads to entangled, unmaintainable systems. On the other extreme, strict hierarchical messaging trees, while clean, often become too cumbersome to scale.

Instead, we embrace a pragmatic, “least-worst” architectural decision: introducing a message broker — RabbitMQ — to mediate communications. This choice not only simplifies module interactions but also fosters testability: individual modules and their interactions can be mocked, enabling everything from unit tests to full integration tests with ease.

Yet, a system is only as good as its ability to reveal its own behaviour. Borrowing from modern micro-service architectures, we extend observability into our system by integrating OpenTelemetry standards. We leverage tools like Loki and Grafana to visualize logs and events, creating a window into the living, breathing system.

Throughout the talk, I’ll reflect on lessons learned from the trenches: why the “principle of least astonishment” is vital, why I never strive for architectural purity at the expense of pragmatism, and why seeking out wisdom from smarter communities accelerates your own growth.

This talk will take us from a humble LabVIEW VI to a modular, observable application, without losing sight of simplicity, adaptability, and - sometimes - even joy in building robust systems.

https://www.gdevcon.com/

Follow us on Social Media
Flickr: https://www.flickr.com/photos/gdevcon/
Instagram:   / gdevcon  
Facebook:   / gdevcon  
LinkedIn:   / gdev.  .
Twitter:   / gdevconference  

Video Copyright (c) Louis James-Parker (All rights reserved). Use is granted to GDevCon Limited under license.
#LabVIEW #GDevCon