Commit Link: https://commits.kde.org/gcompris/fced0df7234fce50979cb261e5b6b61a3fde7b28
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jul 1 2018
May 22 2018
May 10 2018
May 9 2018
Apr 8 2018
Remove the name l10n daemon script and I also removed the duplicate names from the list.
Apr 7 2018
Mar 24 2018
Sorry Sorry Sorry...
Mar 23 2018
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.
Mar 22 2018
the created new header file (ApplicationSettingsMock)
Mar 21 2018
I am doing the mistake in the adding a protected constructor so, it gives the ambiguity error.
Mar 20 2018
Is this possible solution can be acceptable ??
Mar 18 2018
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.
Mar 16 2018
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
Mar 12 2018
yes, I agree with you that if the test is crash during the running it will change the default settings of the application.
Mar 11 2018
Now the unit test is not changing the default configuration of the application.
Mar 10 2018
Mar 4 2018
Mar 3 2018
Thanks for considering my patch.
Mar 2 2018
Pointer is removed
make the change in the autotest
Mar 1 2018
Feb 21 2018
Feb 17 2018
Feb 15 2018
Feb 2 2018
struct is removed
Feb 1 2018
the test is now data-driven test
Jan 31 2018
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
Jan 28 2018
Updated!