Burkhard Stubert

Can We Use Trunk-Based Development for Legacy Software?

by Burkhard Stubert
2022/10/03

Not right away! Trunk-Based Development requires that the software builds and passes enough tests, before we integrate our changes into the main branch (a.k.a., trunk). We have enough tests, if breaking the software is highly unlikely. By definition, legacy code has no or not enough tests. Hence, we cannot apply trunk-based development right way, but should evolve our development process towards it.

by Burkhard Stubert
2022/09/252022/09/25
2 Comments

We start with unit tests reading a file line by line with QFile. Unit tests accessing the file system are not considered unit tests, as they may be slow and may depend on each other in surprising ways (see A Set of Unit Testing Rules by Michael Feathers). In a first step, we encapsulate QFile in a class TextFile and provide a fake implementation representing the file as a list of strings kept in main memory. In a second step, we introduce an interface, from which the product and fake implementations derive. We can now apply TDD to classes accessing files.

by Burkhard Stubert
2022/08/282022/08/29

Signals and slots are my favourite Qt feature, as they make loose coupling between components or between layers super easy. I miss them most when I must write pure C++ code without the Qt goodies. I invite you to follow along while I translate signals and slots into function-object member variables and lambda functions, respectively.

Applying TDD to HAL Drivers with Memory-Mapped I/O

by Burkhard Stubert
2022/08/032022/08/11

A client recently asked me to help them get a legacy HAL driver under test. They want to use TDD to maintain and extend the driver. We ran into a couple of problems, because the tests run on a 64-bit computer, whereas the production code runs on a 32-bit microcontroller. I’ll explain the problems and how to solve them.

Visualising the Architecture of Qt Embedded Systems: Context and Container Diagrams

by Burkhard Stubert
2022/07/112022/07/11

I never got the hang of UML: overly complicated, hard to understand, too close to code. Hence, I was skeptical about C4 diagrams when I… Read More »Visualising the Architecture of Qt Embedded Systems: Context and Container Diagrams

Setting Up Yocto Projects with kas

by Burkhard Stubert
2022/06/242022/06/24

Kas makes the setup of a Yocto build environment super simple and super fast. We call kas with a project configuration file: kas-container build ./eu-terminal-distro.yml. Kas starts a Docker container, clones the layer repositories, initialises the Yocto configuration files (local.conf and bblayers.conf), and starts building the embedded Linux system. Most Linux BSP providers don’t make a kas configuration file available. I’ll show how to convert a repo manifest file into a kas configuration file in this post.

A Basic Continuous Integration Pipeline with GitHub Actions

by Burkhard Stubert
2022/06/062022/06/06

In a previous post, I built a basic CI pipeline with CTest that uploaded its results to a CDash board. It worked fine except that we had to start the pipeline manually from the command line. In this post, we define a pipeline with GitHub Actions that runs the CI pipeline whenever a developer pushes a code change to a GitHub repository.

by Burkhard Stubert
2022/05/172022/05/17

The post Guide to the Total Cost of Ownership of Open-Source Software by Peter Schneider (The Qt Company) provides a smorgasbord of alternative facts why we should not use Qt LGPL but instead buy Qt Commercial. I can’t miss the irony that Schneider like many of his sales colleagues are bad-mouthing Qt LGPL to promote Qt Commercial. Qt LGPL and Commercial share the same code.

3 functions: 2 covered by tests, 1 uncovered

Building a CI Pipeline with CTest and CDash

by Burkhard Stubert
2022/05/02

We can use CMake, CTest and CDash to build a basic Continuous Integration (CI) pipeline. The pipeline builds the applications, runs the tests, collects coverage information and uploads all the results to a dashboard on a web server. All this is controlled by one CMake script executed by CTest.