Instead, we could actually test the real code by just adding a writemock server to AbstractIdeContextTest that serves the directory content and dynamically delivers it as TGZ file (or whatever the URL suffix may be, we can also support ZIP, but we do not plan to support MSI, DMG, PKG).
Then the dummy urls files need to point to the wiremock server and should be in the following format:
Here ${testbaseurl} will be replaced with the base-URL to the wiremock server such as http://localhost:8765 while the port-number is randomly generated (see #223).
The values for «tool», «edition» and «version» should be obvious and even though they are kind of redundant since the urls file is already in a folder structure containing exactly this information, I would still propose to add this explicitly.
I suggest the download folder to avoid clashing conflicts with other aspects that may be needed to be mocked with wiremock in the same test.
The «filename» should typically be «tool»-«version».tgz but as needed by the test, this could also be in the format used by the real download (e.g. zip extension, different file-name-structure).
The wiremock server should react to any GET request inside the download folder.
It should then be able to extract «tool», «edition» and «version» as well as the file extension from the URL.
Only tar.gz with its synonym tgz and zip with its synonym jar will be supported as extensions (not msi, dmg, pkg, etc.).
The wiremock rule for this will then find the folder with the mocked software as done by the current implementation and create an archive package on the fly via GZip, Tar, and Zip streams just like we do on extract method but vice-versa (compress instead of extract).
Currently for our integrative tests of commandlets we added a hack that will override the regular software download with a test-implementation that copies a folder recursively instead: https://github.com/devonfw/IDEasy/blob/4673d682ca638ca1476168186ace40d5b7e47125/cli/src/test/java/com/devonfw/tools/ide/repo/ToolRepositoryMock.java#L45
Instead, we could actually test the real code by just adding a writemock server to
AbstractIdeContextTestthat serves the directory content and dynamically delivers it as TGZ file (or whatever the URL suffix may be, we can also support ZIP, but we do not plan to support MSI, DMG, PKG). Then the dummyurlsfiles need to point to the wiremock server and should be in the following format:Here
${testbaseurl}will be replaced with the base-URL to the wiremock server such ashttp://localhost:8765while the port-number is randomly generated (see #223). The values for«tool»,«edition»and«version»should be obvious and even though they are kind of redundant since theurlsfile is already in a folder structure containing exactly this information, I would still propose to add this explicitly. I suggest thedownloadfolder to avoid clashing conflicts with other aspects that may be needed to be mocked with wiremock in the same test. The«filename»should typically be«tool»-«version».tgzbut as needed by the test, this could also be in the format used by the real download (e.g.zipextension, different file-name-structure).The wiremock server should react to any GET request inside the
downloadfolder. It should then be able to extract«tool»,«edition»and«version»as well as the file extension from the URL. Onlytar.gzwith its synonymtgzandzipwith its synonymjarwill be supported as extensions (notmsi,dmg,pkg, etc.).The wiremock rule for this will then find the folder with the mocked software as done by the current implementation and create an archive package on the fly via GZip, Tar, and Zip streams just like we do on extract method but vice-versa (compress instead of extract).