(cherry picked from commit 6bdc6089)

If items are not refreshed, the final piece (causing the game to be
over) will be invisible. With this change, it will be correctly
displayed, making it obvious why the game is over.

To be able to test the next step in the bugfix, I need to verify the
actions taken on a KBlocksSvgItem object. Thus, I want to replace it
with a mock object. To make this possible, I have created a
SvgItemInterface class and replaced all necessary KBlocksSvgItem
pointers with SvgItemInterface pointers.

This function makes it more difficult to build unit tests for
KBlocksWin. A better way is to make this a public member and call it
explicitely after the KBlocksWin object has been created.

Complex objects being created in constructors is always a big headache
for unit tests, particularly in C++, because constructor calls can't be
avoided and neither can the work be delegated to a virtual member
function.

Instead of creating the objects, KBlocksScene now takes them as input
parameters.

This reduces the number of warnings in the UnitTest-KBlocksWin test
suite to one.

KBlocksView actually stored two pointers to the same Scene object. The
parent QGraphicsView stores a QGraphicsScene pointer, accessible via
scene() and setScene(). And KBlocksView also stored a SceneInterface
pointer as a private member function.

This could lead to confusing behavior. For example, calling setScene()
on the KBlocksView object only replaces one of the two pointers. I have
removed the private mpGameScene member. The scene is now always accessed
via the scene() interface.

This requires that the cpp file is compiled into a new KBlocksTesting
library against which the KBlocksWin test is linked.

The status was determined by whether single games were created before
the call to deleteSingleGames(). The better way to check this is to use
the new hasSingleGames() functionality as it is now done in KBlocksWin.

Using this new functionality, the KBlocksWin::stopGame() method can be
improved and made more readable. The check if single games were created
are now made explicit.

To fix the issue, I introduced a test whether the game logic object has
created single games (by trying to access one). Only if the game logic
object has single games, stop game and delete single games is called.

I have also confirmed by manual testing that the game no longer crashes
when (re)starting a game after the first one.

The test is not as unit-test-y as I would like: Several QWARN are
issued. Furthermore, there is another option to improve usability:

The last piece is also placed ontop of an existing piece, triggering a
game over. However, this final piece is still invisible.

To fix the bug I am targeting, stopGame() triggers an update of the
layout, which includes processing the remaining game actions. To do
this, the corresponding single game objects need to still exist.

In this commit, I have just created the test. It is currently failing.

To be able to sense the actions performed on the game logic element, I
want to be able to replace the GameLogic with a Mock object.

Removed function with fully commented-out body that was never used
anywhere.

The goal is still to be able to use a MockScene in KBlocksWin that can
be used in unit testing.

Later on, I want to create a MockScene object in order to sense the
changes done to the scene by the KBlocksWin class.

Calling updateLayout() means that all remaining game actions are
processed when the game is intended to be stopped. This has the effect
that the play area is updated before the highscore window is shown,
not at a later time.

BUG: 407244

Use an initializer list in the constructor to default-initialize the
public member variables.

Now, the final piece does correctly move into place at the end of the
game. But some improvements are still possible:

1) The piece only moves to the correct location after the highscore
window is displayed (and closed).

2) The piece that could not be placed and ended the game is invisible.

The test is currently failing: KBlocksItemGroup::updateGame() does not
call updateLayout() when the game is over. This means that the final
game actions are not processed.

To be able to instantiate a KBlocksItemGroup in a test suite, several
mock classes need to be created.

Similar to KBlocksGraphics, I want to abstract out the interface of
KBlocksSound, so that I can create a MockSound class to use in unit
testing.

I want to bring KBlocksItemGroup under test. To do this, it is
inconvenient to instantiate it with a KBlocksGraphics object. Instead,
I have extracted the interface and will create a MockGraphics class
which will fake the Graphics object.

Following Albert Astals Cid's advice and make them more idiomatical.

From the ecm_add_app_icon documentation:

  The given icons [...] will be added to the executable target whose
  sources are specified by <sources_var> [...]

It will probably fail with the sources_var being defined in the
subdirectory and used for the library. In any way, the new version
is cleaner and therefore preferable in any case.

This statement was put there since the settings.h and settings.cpp files
would be generated in the base directory. The statement was never
necessary, as the kconfig_add_kcfg_files command already takes care of
the include path.

It is standard procedure to put the configuration files alongside the
source files. I find it the cleanest solution to put them in a dedicated
subdirectory, such as config/ (as done for Konsole and Yakuake, for
example).

This sounds better than having "lib" twice in the name. Also, further
libraries could follow the same pattern, e.g. KBlocksTesting, KBlocksAI,
etc.

The main executable then only builds main.cpp and links against this
library. The reason for this move is that a library is necessary so that
the test suites can link against it, too.

The CMake documentation *strongly* discourages this. When using GLOB,
CMake would not recompile if a new source file is added and the
CONFIGURE_DEPENDS flag may not work reliably.

The main directory has become quite cluttered. It contained 24 non-source-code
files together with 74 .h and .cpp files. All source code files have been
moved to a new directory named 'src'.

Julian Helfferich authored Dec 06, 2020 and Julian Helfferich committed Jan 15, 2021

The pipeline is based on the main CI-tooling templates ci-before.yml
and ci-applications-linux.yml

Julian Helfferich authored Dec 06, 2020 and Julian Helfferich committed Jan 15, 2021

Currently, a whopping 0% of the code is under test. This might or might
not change in the future.

Julian Helfferich authored Dec 06, 2020 and Julian Helfferich committed Jan 15, 2021

The necessary infrastructure has been put in place to write unit tests
using the QTest framework. I have followed the corresponding guideline:

https://community.kde.org/Guidelines_and_HOWTOs/UnitTests

and referred to the setup of Okular unit tests, where the guidelines were
not clear.

(cherry picked from commit fc4c82de)

(cherry picked from commit 9d9c1051)