In recent years Low-Code has seen a surge in popularity amongst companies to speed up their workflows. Yet, scientific work on Low-Code is still in its infancy. We set out to investigate the presence of anti-patterns within Low-Code applications. Given the typically less technically inclined nature of Low-Code developers, as well as the specific use cases of Low-Code in general, we expect that these anti-patterns differ from traditional programming languages. We apply a graph-based methodology to mine edit patterns across real-world commit data supplied to us by Mendix, one of the leading platforms in the Low-Code space. Additionally, we discuss the lack of current guidelines in the Low-Code field. While we are able to find common edit patterns using our approach, linking them to anti-patterns remains difficult in practice. We do establish that Low-Code in Mendix might lack reuse-ability and that the Low-Code often revolves around a few distinct tasks. However, there is a current lack of quality data available to properly assess the development practices of Low-Code developers and anti-patterns, increasing the availability of high-quality data is essential for further research in this area.

Amplified test cases created by DSpot and TestCube often contain unnecessary statements that impact the readability of the tests in question. As a part of the effort to make these amplified test cases more developer-friendly, we investigate (dynamic) slicing, taint analysis and static analysis as approaches to remove redundant statements. In addition, we evaluate a simple static analysis
approach that we implemented into DSpot. Our results show that the implemented approach works well: while being rudimentary, it is able to remove a significant portion of the redundant statements in the amplified test cases. A problem with removing redundant statements is the fact that it, at least for the approaches we discuss in this paper, will take a significant amount of time depending on the size and quality of the original tests. While the removal of the statements themselves is relatively fast, especially when using our implemented static analysis approach, verifying that the tests still work as intended through mutation testing is resource-intensive.