Re: Automated Tests and KConfig
Hello, On mardi 18 août 2020 01:42:29 CEST Albert Astals Cid wrote: > El dilluns, 17 d’agost de 2020, a les 23:57:20 CEST, Matthieu Gallien va escriure: > > Hello, > > > > I have been wandering if there is a general solution to use KConfig inside > > automated tests. > > > > I have been having difficulties (and another contributor to Elisa) to > > integrate the singleton object lifetime with the need to run different > > tests isolated and using the singleton (including code to initialize it). > * > Call > Elisa::ElisaConfiguration::instance(("testfoo")); > in the initTestCase() function of each testfoo app? In my case, I tried doing that but because the code I was testing is also calling it, I had troubles. The currently failing test can be solved this way. Thanks for the help. > Potentially include QStandardPaths::setTestModeEnabled(true) too? Somehow, I had overlooked that. I will definitely makes good use of that. > Or when you say "test" you mean each of the subtests inside a test app? > > If you need to reset the values between them i guess you can just call > setDefaults() in the init() function of each test app? This is what I need. I also had overlooked that. > Cheers, > Albert Thanks Albert for the help > > One problem I am trying to solve is calling ::initialize > > multiple times. > > > > One solution I have been using is encapsulating all KConfig code inside a > > class and fake it in the tests. Is there other solution ? > > > > Thanks > > > > Best regards Best regards
Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed
On 15/08/20 19:20, Friedrich W. H. Kossebau wrote: > Hi, > > what is markdownpart you ask? A KParts plugin allowing to view markdown > documents rendered e.g. in Kate's preview plugin, Ark, Krusader or Konqueror, > being mainly a wrapper around QTextDocument::setMarkdown & QTextBrowser. > See here it being used with Kate's preview plugin: > https://cdn.kde.org/screenshots/markdownpart/markdownpart.png > Note: for now Qt 5.15-only, 5.14 possible but untested. > > I would like to propose markdownpart for a move into community maintenance > mode and becoming part of release service Hi Friedrich, why not merge this plugin into kate instead? > > Cheers > Friedrich > > Cheers, Elvis
Re: KDEREVIEW: Proposing utilities/markdownpart to become community/release-service-managed
On 17/08/20 23:04, Friedrich W. H. Kossebau wrote: > Hi Elvis, > > Am Montag, 17. August 2020, 22:43:37 CEST schrieb Elvis Angelaccio: >> On 15/08/20 19:20, Friedrich W. H. Kossebau wrote: >>> Hi, >>> >>> what is markdownpart you ask? A KParts plugin allowing to view markdown >>> documents rendered e.g. in Kate's preview plugin, Ark, Krusader or >>> Konqueror, being mainly a wrapper around QTextDocument::setMarkdown & >>> QTextBrowser. See here it being used with Kate's preview plugin: >>> https://cdn.kde.org/screenshots/markdownpart/markdownpart.png >>> Note: for now Qt 5.15-only, 5.14 possible but untested. >>> >>> I would like to propose markdownpart for a move into community maintenance >>> mode and becoming part of release service >> >> Hi Friedrich, >> >> why not merge this plugin into kate instead? > > Let me answer with another question: > why with Kate and not with Ark or with Krusader or with Konqueror or any > other > potential KParts plugin user where Markdown viewing often is useful? > > Bundling with Kate would be a rather random choice IMHO. And > a) make it challenging for packagers to split out an independent packager for > the markdown kpart with all the files belonging to it > b) make it harder for anyone interested in hacking on it, as they would have > to also care about the whole Kate repo and its complete build system, when > they just want to improve the markdown viewer e.g. for Ark. > > But not my call, after all I offer this to KDE community for adoption, sou > your choice. My bad, I didn't realize this was a KPart plugin. The Kate screenshot you linked got me confused :p Then yes, a stand-alone package makes sense indeed. > > Cheers > Friedrich > > Cheers, Elvis
Automated Tests and KConfig
Hello, I have been wandering if there is a general solution to use KConfig inside automated tests. I have been having difficulties (and another contributor to Elisa) to integrate the singleton object lifetime with the need to run different tests isolated and using the singleton (including code to initialize it). One problem I am trying to solve is calling ::initialize multiple times. One solution I have been using is encapsulating all KConfig code inside a class and fake it in the tests. Is there other solution ? Thanks Best regards