Does Low Code Mean Low Testing? A #PNSQC2022 Live Blog

There has been a number of increases in various software development and deployment options referred to as "low code" or "no code". What this usually means is that the software development tools in question have created systems and abstractions to either hide the code created or to effectively minimize the amount of new code that needs to be written based on built-in methods and implementations. Intriguing, but with that methodology, does that limit our ability to test or interact with systems?

Jan Jaap Cannegieter

Jan Jaap Cannegeiter argues that many of these systems do have benefits and ways of interacting with how a system is pieced together. BY dragging and dropping elements that have already been constructed/implemented, lots of reusable pieces can be put together more like Lego blocks rather than by writing individual code blocks and methods. The idea of reuse and repurposing is not new. Animated programs have been doing this for decades. Heck, Hanna Barbera was famous for reusing whole blocks of animation and repurposing them in different scenes (ever noticed that The Brady Kids and The Archies when they perform their "songs" on their respective cartoons have the exact same movements ;)?). 

Again, the idea and benefit of low-code platforms is that they have four layers: processes, screen flows, business logic, and data model. The top two are likely the easiest to plug together, while the bottom two probably have the biggest challenges to implement and make reusable and pluggable. However, I would assume that, if the business logic and data model were "understood", then there would be an easier way to plug everything together. I can help but ask... who tests the business logic and the data model? How do we know that these are correct? With code, we can research and figure out whether or not the implementation is effective or if we are missing key areas or have areas we can exploit. If these are abstracted away, I'd argue that those areas become harder to test because we cannot verify (or we would have difficulty verifying) what that business logic actually is. That's not to say we can't test the logic gates but I feel we leave a lot on the table that doesn't get properly examined.

Anyway, I picked this talk because I specifically do not have a lot of experience with this topic or these tools. Does my skepticism hold up to scrutiny? I honestly do not know but I'm curious to explore more of these options so I can see if I'm right or wrong. Let's just say the jury's out at the moment but I freely confess my biases and doubts ;)