Test fixtures with identical names appear as one in the Test Explorer

Issue #146 resolved
Diego Sogari created an issue

Related to issue #86. Since namespaces are omitted from test fixture names, fixtures (and their tests) with identical names show up in the explorer view as the same, which prevents me from seeing and selecting each individual “sibling” test or fixture. You might in all fairness ask why I’m using identical class names in the first place, but we think it makes the code cleaner, because each class belongs to a namespace which is the name of the unit where it is declared.

Having said that, I can tweak the TestInsight.DUnitX unit (with the patch file attached) to make test fixture names include their full qualified name, which works around this problem, but unfortunately it spoils the feature of double-clicking in the test name to go to the corresponding source code.

Let me give a good motivation to have a test project with lots of units and reasonable hierarchy depth. In modern CI systems, it is commonplace to split a pipeline/workflow in multiple jobs, each of them doing a very specific task (e.g. debug build, unit test, static analysis, an so on). For this to work, there must be a way to “pass” the artifacts produced by one job to dependent jobs. This is accomplished by uploading the artifacts to a server, so they can be downloaded when necessary. However, depending on the CI infrastructure, the upload/download mechanism can be costly, both in terms of time and bandwidth, especially when there are many repositories with lots of pipelines being triggered a day and there are limited runners to run them.

Going back to our problem, if you try to compile a test project with many third-party dependencies (DUnitX, Delphi-Mocks, JCL, FastMM, etc.), the resulting executable gets rather large, even more so because we need to compile it in Debug mode. To make matters worse, in order to extract test coverage results we need to generate a detailed .map file, which is also large (although it can be more efficiently compressed as it is a text file). So, to make my point: compiling a single test project seems to save disk space and upload time, compared to multiple test projects, simply because the same compiled object files (from native and third-party libraries) are not replicated across multiple executables and .map files.

To illustrate my point, I have actual facts from one of our repositories:

Measure Multiple projects Single project
Executable size (KB) 36165 + 29781 37199
Map file size (KB) 29887 + 24366 30752
Compressed size (KB) 22928 12951

The resulting artifact from a single test project is almost 50% smaller in comparison to the original. This reduction could be even greater if the original artifact had more executables and if most part of the code is from native and third-party libraries.

Please let me know what you think, and thanks for sharing this awesome IDE plugin with the community!

I’m using Delphi 10.4 Version 27.0.38860.1461 on Windows 64-bit.

Comments (2)

  1. Log in to comment