2.8 KiB
Self-Assessment
Two Real Difficulties
1. Maintaining TDD discipline under time pressure
Sticking to a strict test-first workflow throughout the session was genuinely hard. Between the deadline and the accumulated fatigue of a full day of work beforehand, there were moments where the temptation to just write the implementation and then fill the tests was real. I did not always resist it. Some tests were written after the fact rather than before, which is something I am aware of and want to be honest about.
2. Designing testable seams at the IPC and sysfs boundaries
The components that most needed testing were also the ones most coupled to external resources: a live socket and a real sysfs path. The difficulty was finding the right abstraction level, too thin and the tests require actual kernel resources; too thick and you end up testing your mocks, not your logic. The solution was to inject the transport as a plain std::function callback into the producer, and to point the sysfs reader at a controlled fake file on disk. Both approaches keep the core logic testable with no sockets, no threads, and no Qt, but arriving at that boundary (deciding what to abstract and what to leave concrete) required more iteration than I anticipated.
Alternative IPC Mechanism Considered
I evaluated POSIX shared memory with semaphores as an alternative to UNIX domain sockets. The theoretical appeal is clear: no serialization, no kernel-mediated data copy, potentially lower latency. However, I am considerably less practiced with shm_open/mmap/sem_post than I am with socket-based communication, and more importantly, shared memory is significantly harder to unit-test in isolation. Sockets expose a clean, file-descriptor-based interface that maps naturally to mock-able abstractions. Shared memory regions and semaphore lifecycles would have added complexity to the test harness for uncertain gain at this data rate. Domain sockets were the pragmatic choice.
Design Decision Changed Mid-Development
Initially I had planned a looser boundary between the core logic and Qt, with the producer potentially depending on Qt primitives for threading or signalling. Early on, I decided to keep Qt strictly confined to the GUI layer and the consumer thread, nothing more. The producer, the sysfs reader, and the IPC bridge are plain C++ with no Qt dependency whatsoever.
The reason is simple: that code could be portable. If tomorrow the producer needs to run on a microcontroller, a bare-metal embedded target, or any environment where Qt is not available or not desirable, the only thing that needs replacing is the transport callback. The core logic moves untouched. It also makes unit-testing the producer significantly cleaner and easier, no Qt test infrastructure needed, just standard C++.