Adding cppunit test to ucb.ucp.webdav

classic Classic list List threaded Threaded
5 messages Options
Giuseppe Castagno Giuseppe Castagno
Reply | Threaded
Open this post in threaded view
|

Adding cppunit test to ucb.ucp.webdav

Hi all,

I'm trying to add unit tests to webdav, for the time being limited to
member function that are used internally, that is that don't need a
server to interact with.

Member functions in library ucpdav1 are not exported (so I gather...).

Is the following method allowed to make externally visible member
function that I intend to test? Any downside?

Limited to webdav_ucp::NeonUri as the first to be checked:

diff --git a/ucb/source/ucp/webdav-neon/NeonUri.hxx
b/ucb/source/ucp/webdav-neon/NeonUri.hxx
index cd9fbe9..c5cea8c 100644
--- a/ucb/source/ucp/webdav-neon/NeonUri.hxx
+++ b/ucb/source/ucp/webdav-neon/NeonUri.hxx
@@ -41,7 +41,8 @@ namespace webdav_ucp
  #define DEFAULT_FTP_PORT        21

  // A URI implementation for use with the neon/expat library
-class NeonUri
+// Added SAL_DLLPUBLIC_EXPORT to implement cppunit test
+class SAL_DLLPUBLIC_EXPORT NeonUri
  {
      private:
          OUString mURI;

Thanks,
--
Kind Regards,
Giuseppe Castagno aka beppec56
Acca Esse http://www.acca-esse.eu
giuseppe.castagno at acca-esse.eu
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Adding cppunit test to ucb.ucp.webdav

On 01/19/2016 03:13 PM, Giuseppe Castagno wrote:

> Hi all,
>
> I'm trying to add unit tests to webdav, for the time being limited to
> member function that are used internally, that is that don't need a
> server to interact with.
>
> Member functions in library ucpdav1 are not exported (so I gather...).
>
> Is the following method allowed to make externally visible member
> function that I intend to test? Any downside?
>
> Limited to webdav_ucp::NeonUri as the first to be checked:
>
> diff --git a/ucb/source/ucp/webdav-neon/NeonUri.hxx
> b/ucb/source/ucp/webdav-neon/NeonUri.hxx
> index cd9fbe9..c5cea8c 100644
> --- a/ucb/source/ucp/webdav-neon/NeonUri.hxx
> +++ b/ucb/source/ucp/webdav-neon/NeonUri.hxx
> @@ -41,7 +41,8 @@ namespace webdav_ucp
>   #define DEFAULT_FTP_PORT        21
>
>   // A URI implementation for use with the neon/expat library
> -class NeonUri
> +// Added SAL_DLLPUBLIC_EXPORT to implement cppunit test
> +class SAL_DLLPUBLIC_EXPORT NeonUri

There's two approaches to this ugly problem.  One is as above, with the
downside of increasing the number of global symbols.  The other is to
link a Library's objects directly into a CppunitTest library via
gb_CppunitTest_use_library_objects.  The downside there is that you need
typically duplicate all the Library_*.mk's
gb_Library_set/use/whatever... calls as gb_CppunitTest_... calls in the
CppunitTest_*.mk.

Both approaches suck.  When possible, try to stick with the second one,
though.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

building a shadow test lib with all symbols? (was: Adding cppunit test to ucb.ucp.webdav)

Hi,

On Tue, Jan 19, 2016 at 03:38:32PM +0100, Stephan Bergmann wrote:
> There's two approaches to this ugly problem.  One is as above, with the
> downside of increasing the number of global symbols.  The other is to link a
> Library's objects directly into a CppunitTest library via
> gb_CppunitTest_use_library_objects.  The downside there is that you need
> typically duplicate all the Library_*.mk's gb_Library_set/use/whatever...
> calls as gb_CppunitTest_... calls in the CppunitTest_*.mk.
>
> Both approaches suck.

True. It was "Good Enough"(tm) for the time being "Back Then"[1], but we have
much more tests now. I wonder if we should consider something like creating a
second "shadow" library that exports all symbols, but doesnt get build by
default. Thus e.g. the stuff in sw/Library_sw.mk would create _two_ targets:

 ./instdir/program/libswlo.so
 ./workdir/LinkTarget/libswlo_tests.so

Only the first is made a depended upon by the module (and thus is build
unconditionally). This is the one we build now already, in a "production"
style. The second one is not build by default, until a CppunitTest doesnt
something like:

$(eval $(call gb_CppunitTest_use_test_libraries, sw_uwriter, sw))

which would link against ./workdir/LinkTarget/libswlo_tests.so (which exports
all symbols).

This would:

+ remove the need for duplicating all the build parameters in a bitrotting and
  error-prone fashion
+ remove the need for re-linking the same objects is loads of unittests again
  and again
+ remove the need to export symbols in production just for tests
+ remove the need to think about which set of object files I need to link in a
  unittest
- likely require us to build the targeted libs twice

The last point is a huge disadvantage -- but I wonder if it might be workable
these days, esp. since the static relinking of huge amounts of the same objects
in some 10-20 test libs as we are doing today does not come for free either[2].

Most importantly, once done the incremental cost in adding a new test both in
manpower, build time and discspace is lowered a lot with this.

Opinions?

Best,

Bjoern

[1] Admittedly that likely glorified past and a lame excuse.
[2] As a bonus, one _might_ consider things like building the _tests.so lib with
    DEBUG=T or somesuch by default. I am not entirely sure that would be a good
    idea though (as it would be testing code that is too different from what we
    ship, while not testing the code that we ship).
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: building a shadow test lib with all symbols? (was: Adding cppunit test to ucb.ucp.webdav)

On Tue, Jan 19, 2016 at 11:46:21PM +0100, Bjoern Michaelsen wrote:
> The last point is a huge disadvantage -- but I wonder if it might be workable
> these days, esp. since the static relinking of huge amounts of the same objects
> in some 10-20 test libs as we are doing today does not come for free either[2].

For reference on a master checkout:

du -sch workdir/LinkTarget/CppunitTest/libtest_sw_*|grep total
   35M total

du -sh instdir/program/libswlo.so
   19M instdir/program/libswlo.so

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: building a shadow test lib with all symbols?

In reply to this post by Bjoern Michaelsen
On 01/19/2016 11:46 PM, Bjoern Michaelsen wrote:

> On Tue, Jan 19, 2016 at 03:38:32PM +0100, Stephan Bergmann wrote:
>> There's two approaches to this ugly problem.  One is as above, with the
>> downside of increasing the number of global symbols.  The other is to link a
>> Library's objects directly into a CppunitTest library via
>> gb_CppunitTest_use_library_objects.  The downside there is that you need
>> typically duplicate all the Library_*.mk's gb_Library_set/use/whatever...
>> calls as gb_CppunitTest_... calls in the CppunitTest_*.mk.
>>
>> Both approaches suck.
>
> True. It was "Good Enough"(tm) for the time being "Back Then"[1], but we have
> much more tests now. I wonder if we should consider something like creating a
> second "shadow" library that exports all symbols, but doesnt get build by
> default. Thus e.g. the stuff in sw/Library_sw.mk would create _two_ targets:
>
>   ./instdir/program/libswlo.so
>   ./workdir/LinkTarget/libswlo_tests.so

There can be cases where both libraries end up in the process (like
other libraries needing the first one, or the first one being
dlopen'ed).  That could cause problems with duplicated static data and
symbols exported multiple times, but both those problems are no
different with the current second approach above.
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice