GNOME Bugzilla – Bug 734104
Add automated tests for gedit
Last modified: 2020-11-24 09:57:49 UTC
Created attachment 282243 [details] [review] Minimal test set and needed structure Gedit is highly used core application and should have minimal set of automated tests which can be run under GnomeContinuous environment as InstalledTests.
Review of attachment 282243 [details] [review]: Here is a very fast initial review, please add the copyrights, also gedit is python2 free and I really would like to avoid depending on python2...
Thanks for the really fast response! The copyrights shouldn't be a problem, but I'm not sure how is the dogtail's python3 status.. I will look at it and produce new version of this patch soon.
Here comes some status update: Situation about Dogtail is following: I've re-ported dogtail to python3 and it looks like we could have in few week a rpm package of dogtail3 - fully compatible with python3. Different situation is with behave, the second tool we use. behave's port to python3 is in buggy state and even if I resolve the problems there (what I definitely want to do in very near future), I don't have any influence on behave's maintainers and building python3-behave can be really problematic from this point of view. So, is it a really unbreakable problem to have python2 ONLY for these test, which are primary executed under GnomeContinuous? If so, I would have to freeze this request until all the python3 ports are ready.
Is there anywhere set in the stone that we have to use behave? Good ol' structured programming is 99% of what we need anyway. Otherwise I have a test suite internally, which I could happily work on to port to this test suite, but it is currently completely broken (it was for gedit 3.8, i.e. with the menubar).
Is it to test the UI? Because the UI is an ever-changing thing, and I don't know if it's worth the effort to write lots of test for it. The UI is usually the simple part of the code. The more complicated part, the backend, has already lots of tests in GtkSourceView, but tests are missing for some important features, like syntax highlighting. If lots of tests are written for the UI, it means that when we want to change something in the UI, we need to adapt the tests, which can be cumbersome. The backend code usually changes less.
(In reply to Sébastien Wilmet from comment #5) > Is it to test the UI? Because the UI is an ever-changing thing, and I don't > know if it's worth the effort to write lots of test for it. The UI is > usually the simple part of the code. The more complicated part, the backend, > has already lots of tests in GtkSourceView, but tests are missing for some > important features, like syntax highlighting. Well, don't look it at as mere "test of UI", but as a functional testing. It is done anyway by Red Hat (where the code comes from) and I guess other enterprise distros as well, so it may be as well maintained inside of the Gnome repo. > If lots of tests are written for the UI, it means that when we want to > change something in the UI, we need to adapt the tests, which can be > cumbersome. The backend code usually changes less. Well, I don't think that keeping tests in sync is the primary responsibility of the normal developers. Whoever wants to use the tests should be held responsible for maintaining them, I guess.
Having those tests upstream definitely makes sense, to not repeat work for each enterprise distro.
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.