Digikam test data conventions

Steven Robbins <[email protected]> Thu, 06 Oct 2022 08:19:44 -0500
Newsgroups gmane.comp.kde.digikam.devel
Message-ID <4218353.ejJDZkT8p0@riemann>
On Thursday, October 6, 2022 12:40:38 A.M. CDT Gilles Caulier wrote:

> > Before I start with merge requests, please have a quick look at [1] and
> > let me know if you're OK with the file layout and naming.  There's only
> > four test files at the moment so there's not a well-developed naming
> > convention -- mostly it consists of using a sub-directory named "video";
> > I expect that later there will be one named "images".
> 
> Yes, this is the right way. In fact the best naming convention will be
> to use the same core/tests/...subdirs... names. Each group of
> unit-tests hosted in a same directory must point to a data subdir
> hosted in a similar hierarchy. Like this, this will be very easy to
> found which data files is used for a specific unit test.

I understand.  I do imagine that there will be files that are very much 
component specific.  On the other hand, might there be tests that just need "a 
video file", say?  I imagined that such tests may be distributed in different 
places in the code base.  Right now I'm using them in testing qtav.  But maybe 
it would be useful later for core/avplayer testing?  With that in mind -- 
rather than duplicate to match the usage point -- I advocate naming convention 
that describes the test files themselves.

Also of note is that I use this class to locate them:
https://invent.kde.org/srobbins/digikam/-/blob/feature-qtav-testing/core/
tests/TestDataDir.h 

This is to avoid the use of QFINDTESTDATA that searches in multiple locations 
[1] meaning one needs to understand that algorithm (which I find opaque) and if 
you don't it might inadvertently find the wrong data.

[1] https://doc.qt.io/qt-6/qtest.html#QFINDTESTDATA

Note that while I exposed specific members for the four files here, there is 
also the getVideoFile(string) method for cases where you want a data-driven 
approach with the list of file names in the test code.

If you disagree, I will move the "video" folder.  I plan to use the same files 
for testing things in core/tests/video/qtav/tests.  So would you want the 
directory within digikam-data to be named "core/tests/video/qtav/video" ?
Or something else?
 

> Where are the CMake rules to checkout the unit tests data repository ?

First, note that I will put an entry in the .gitslave file so that you can use 
the "download-repos" mechanism if you choose.

For the CI, I put a custom command and target into the top-level cmake [2]:

add_custom_command(OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/test-data 
    COMMAND git ARGS clone https://invent.kde.org/graphics/digikam-test-data.git ${CMAKE_CURRENT_SOURCE_DIR}/test-data)
add_custom_target(download-test-data ALL DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/
test-data)

The intent is that this becomes a "no-op" if you have already created the 
directory test-data -- say using download-repos.  But I admit that aspect is 
not well tested.

[2] https://invent.kde.org/srobbins/digikam/-/blob/feature-qtav-testing/
CMakeLists.txt#L298
 
> It can be a good idea to patch the README to explain this
> particularity of gitlab CI.

Agree, that is a good idea.  I'll do so and make a mention of the print-codecs 
rule [3].

[3] https://invent.kde.org/graphics/digikam/-/commit/
bbe2f2f5408deb3320029fbac7a738730375cb11

Regards,
-Steve
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEy89k8fa3rclNjyokyeVeL63I9LkFAmM+1fAACgkQyeVeL63I
9LmJ3w//ZIviAZxTh0dTQLM9xo+j/U8JrY5vPkubGD43TDn7b+b7NJ+HeE5R/fsE
9oSPx/acgMYGoOR1PqtGtePpnCTTTOXHzZpTIaw5CstDvlbz5GzVdY0O93VrEhAY
V8C65WKjZ8WpFklDtkz0AEDTtFkt+FximbRtKu1W1qvsrXtQ5dabE3LP5QPKfNqq
s7TY8s4E/bbXYu6xFNH4y04TOIkEmLVir3AWy9BPAU4PsGXKTbkxNzNdq8k2MypI
Y4hQEm58pN4cTxpnP1LfKJUuAZuB+GCeZqwHTEJGElvL4u26Ib1cligI5/JZR1La
TtvuI66Rly2I+mINj3o1zviT9j/ax/z2Nfr8bmojs5I6T8wHE+HhC3NuzNTnXUC5
VxySOJsN9N5QI8BXTnnPVEfUV0pH0cwTezH/kgax8RoJzgnWnSkM+rLsFwpCvyKN
Bk+Vdei/3+/C7iwgJhIMFcU6pglKooq/Xge7vHmtbCe12qx8ETQ5CE4sBNDmuKcu
3AECi5EHaud2GQ6d4iAczBAiGf4+/bKQbBkx8R7LrhUMUMSBDItaToJYO93ZlrFR
paDzN46S8zgTb4RQ3g4nEd/frnwF7bMQUqHEouEjmGf42yE7FMJ753dPW/o/TvZR
HfciPwDpYpimXyv7rMGKW+9V6eBZfGfsmTCCUiu4wgBKyULxbcU=
=zAcw
-----END PGP SIGNATURE-----