Digikam test data conventions

[Gilles Caulier]

Le jeu. 6 oct. 2022 à 15:20, Steven Robbins <steve at sumost.ca> a écrit :
>
> 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.

yes

> On the other hand, might there be tests that just need "a
> video file", say?

yes, it's possible, for ex, metadata engine can use a video file for
testing. This is completely separated than QtAV code which require
alos video files.

We can imagine the same for the database scanner to test information
used to populate the collection.

>I imagined that such tests may be distributed in different
> places in the code base.

The goal is code to test is located somewhere in core, generally
grouped by function (ex metadata engine which group low level function
based on Exiv2, backend wrapper using ffmpeg, exiftool, imagemagick,
settings, etc...)

>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.

There is no plan to test high level programs such as showfoto,
digiKam, or avplayer. The unit-tests are well named : it's to test low
level small features, not a global program. For this kind of tests,
it's more a job for developers in target computers, because it
requires user interactions, even if I know that GUI unit tests are
possible with QTest API, but to have experienced in my office this
way, it's not very suitable and in fact a waste of time. It's better
to concentrate all efforts to check small features, this will be more
efficient, and after all, if we do it well, we will check the most
important cases to test..

>
> 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.

Ok, this point is important to port metadata engine unit tests when
data files will be migrated to the separated repository.

>
> 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?

yes, the same hierarchy in test code and test data repositories will
be homogeneous. We will seen if this strategy will be the best for the
future.

>
>
> > 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.

Hum, well don't forget to comment in cmake scripts too, it's important...

Best

Gilles