Commit Link: https://commits.kde.org/gcompris/fced0df7234fce50979cb261e5b6b61a3fde7b28

Remove the name l10n daemon script and I also removed the duplicate names from the list.

Sorry Sorry Sorry...

In D11034#231907, @jjazeix wrote:

Can you check that if you instantiate a ApplicationSettingsMock object, then use ApplicationSettings::getInstance(), it returns the mock instead of creating a new ApplicationSettings object?
As we use it this way on other classes (like ApplicationInfo), it would be better that, for tests, the getInstance() returns the mock instead of the real one (else we'll have the same issue as we had here, writing on the real configuration).

Except this point (and the small one regarding parameters ordering), it seems good to me, I'll take a closer look this week-end to integrate it

Change in the order of the parameters, Make the QObject paramete in last.

the created new header file (ApplicationSettingsMock)

I am doing the mistake in the adding a protected constructor so, it gives the ambiguity error.

Is this possible solution can be acceptable ??

I am sorry, I haven't seen that you push it and make necessary changes as required.

Now, extra-cmake-modules are not compulsory to compile the application but it required to run the unit test and other things.

In D11034#226275, @jjazeix wrote:

In D11034#224142, @himanshuvishwakarma wrote:

yes, I agree with you that if the test is crash during the running it will change the default settings of the application.

So, I think that the solution is that, I don't have to use the main settings( ~/.config/gcompris/gcompris-qt.conf ) of the application in our unit test. To achieve this, I tried with making DummyApplicationSettings class by inheriting the ApplicationSettings class and change access specifiers of m_config to protected and then tried to change the config file location but there is NO any function in the QSettings to change the location of the config file. So dummy class also changed the main settings of the application while running the test.

The main problem is NO way to change the default location of the config file in the object of QSettings class.

maybe wrong approach.
or
maybe some other method may present to do the tests. but presently I have no idea what to do next in this test, I am searching... if anything I will get, I will update the diff.

If you need to add some protected methods to change the settings, you can

Now, I removed the part which is changing the default settings of the GCompris

yes, I agree with you that if the test is crash during the running it will change the default settings of the application.

Now the unit test is not changing the default configuration of the application.

Thanks for considering my patch.

Pointer is removed

make the change in the autotest

struct is removed

the test is now data-driven test

I have some difficulties in making this test into the data-driven test.
For the data-driven, I have the problem in defining the array type the data
function. how to use this function to store the array type values

Updated!