| Age | Commit message (Collapse) | Author |
|---|
|
The sc_subsequent_filters_test was failing because of a lock file
because it did not use the unittest configuration.
Refactor gb_CppunitTest_use_configuration so it uses both the instdir
and unittest configuration to prevent such errors.
In case there ever is a test that does not work with the unittest
configuration it should call gb_CppunitTest_use_instdir_configuration.
Change-Id: Ibc00d42f8b6102d50d922f51173120798fa45c6e
|
|
This required some changes to the framework:
* Init-/DeInitVCL is no longer done per individual test in BootstrapFixture, but
once per CppunitTest invocation in a new vclbootstrapprotector (similarly to
the exisiting unobootstrapprotector). CppunitTests that need VCL now need to
declare gb_CppunitTest_use_vcl.
* For things to work properly, the UNO component context needs to be disposed
from within DeInitVCL (cf. Desktop's Application::DeInit called from
DeInitVCL). The easiest solution was to introduce an
Application::setDeInitHook (where the hook is called from DeInitVCL)
specifically for vclbootstrapprotector to call.
* PythonTests don't (yet) call DeInitVCL; they still hook into
BootstrapFixture's original test_init functionality (to call InitVCL), and do
not make use of the vclbootstrapprotector.
Change-Id: I4f3a3c75db30b58c1cd49d81c51db14902ed68b2
|
|
Change-Id: I0f2453e23d18597cfe1ad2a4cd4902b15f0a8f7d
|
|
Change-Id: I4c688a4aeedcae56ed6404574bd1bb392d4190cb
Reviewed-on: https://gerrit.libreoffice.org/6311
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
..instead of .xcu files in solver/*/xml/registry
when running unittests and gengal.
Change-Id: I390a6c531d653acca7ef3379c49fe65fcb8f3c2a
Reviewed-on: https://gerrit.libreoffice.org/6057
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I0639b2c69f5f111e37e5566bf4cbea6719de8789
|
|
(Windows throws an Error on this.)
Change-Id: Ica3aeac294d3a32a4faa6837309a0fb5d8d15b92
|
|
Change-Id: I34df96334478b10f151e630188f45e6ce0487f1a
|
|
Change-Id: Ibfd017c23cf510bf481d60b1e836654fd7240df0
|
|
This opens an "empty" firebird-based .odb and tests that it is possible
for the firebird-sdbc driver to open the embedded database.
"empty" denotes that the .odb is marked as using embedded firebird
but doesn't in fact contain any .fdb file within. This is usual state
of a .odb directly after creation using the "New Database" dialog when
the sdbc driver first opens the database.
Change-Id: I83941c05b6328d8419dca49121988640c6f887bc
|
