Stephan Bergmann
d15ff312ad
There are occasional failures of Jenkins "Daily Screenshot Build on Windows" like <https://ci.libreoffice.org/job/lo_tb_master_win_screenshot/324/console> and <https://ci.libreoffice.org/job/lo_tb_master_win_screenshot/332/console>, always failing with > C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win_screenshot/test/source/screenshot_test.cxx(84) : error : Assertion > Test name: ReportdesignDialogsTest::openAnyDialog > assertion failed > - Expression: aNew.IsOpen() > - Failed to open <C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win_screenshot/workdir/screenshots/modules/dbreport/ui/condformatdialog/CondFormat.png>: 796 (where 796 is ERRCODE_IO_NOTEXISTSPATH). Beats me how that can happen, when ScreenshotTest::implSaveScreenshot first creates the dir and then the file-in- dir (and it is rather unlikely that something else deletes the dir in the meantime, for various builds of that Jenkins bot, always for the same dir workdir/screenshots/modules/dbreport/ui/condformatdialog/), and why it always happens for exactly the same file, workdir/screenshots/modules/dbreport/ui/condformatdialog/CondFormat.png during CppunitTest_reportdesign_dialogs_test. However, one curiosity was that the dir's URL was computed with m_directories.getURLFromWorkdir(aDirname); (without a leading slash inserted before aDirname) while the file's pathname was computed with m_directories.getPathFromWorkdir("/" + aDirname + ...) (with a leading slash inserted before aDirname). Turns out that SvFileStream accepts a URL as well as a pathname, so normalize the computation of the dir's and the file's URL. Maybe that will give a clue why that Jenkins bot sometimes fails. Change-Id: I53b59b51ffc4355c45aa0ca72f6e187cf2010f92
Test harness code for C++ unit testing Many of these tests are run during the build process. In that case on unix, if a test fails follow the error messages to debug it under gdb.