Writing tests for Gedit plugin development (Python)

Applications
, ,
1

I was wondering whether there are instructions somewhere on how to develop and run automated tests for Gedit plugin development, specifically for Python.

I’ve done test development and automation for Python CLI and Web applications, but I expect to find new challenges in GUI software (though I’m not sure; it might be that all dependencies can easily be mocked away).

It would be great to have a recipe, a predefined strategy, on how to go about writing the tests. Likely, there are a few entry points of when the plugin is called, so the way (Python) plugins are tested is probably “always the same”, generally speaking. A uniform approach to a test automation setup would also help, I guess.

Any hints are greatly appreciated!

2

I (unsuccessfully) tried a Tox test automation setup, like this:

[tox]
envlist = py

[testenv]
description = Unit tests
sitepackages = true
deps =
    coverage[toml]
    pytest
commands =
    coverage run -m pytest {posargs:tests}
    coverage report

With a simple test, like this:

"""FILE: tests/test_plugin.py"""
from reST import ReStructuredTextPlugin

def test_init():
    """Can the plugin be instantiated successfully?"""
    plugin = ReStructuredTextPlugin()

The example plugin I try to run tests on is gedit-reST-plugin.

Notes

  1. The sitepackages = true is needed for import gi to be successful. I’d rather have Tox install the Python bindings as test dependencies, which would allow us to test against a variety of its versions (not just the one installed locally on the developer machine), but that requires development headers and various other preparation for PyGObject and Pycairo.

  2. Running a simple test still fails in at least two places (which are roughly import errors of various types), although the plugin runs successfully when used with Gedit on my Ubuntu 22.04.3 LTS machine.

    gi.require_version('Gedit', '3.0')

    causes ValueError: Namespace Gedit not available. When I comment out that line of code the test hits here next:

    from gi.repository import GObject, Gedit, PeasGtk

    causes ImportError: cannot import name Gedit, introspection typelib not found.

Is there a sensible way to work around those issues?

3

The short answer is: the GUI parts are not unit-tested, but backend functionalities can be (and usually are for new code).

4

I don’t think it’s about front-end, functional or acceptance testing, vs. unit testing. The primary problem of not having (unit) tests is: No-one runs over your entire code base. – If you can’t run through the (GUI) code, mocking out things that are hard to provide for automated tests, you also can’t test the entire back-end functionality, by a certain amount of logic.

How can I make the test setup behave like my productive system, on my productive system, for the start? I need the information of how GNOME apps are deployed. The Python site-packages are just one piece of the puzzle, unfortunately.

How is back-end functionality tested, if that’s actually different, as you hint on? Is there a representative example of some GNOME application test setup anywhere?

5

Now I have the time to write a longer answer :slight_smile:

To unit-test backend features (in the case of gedit this may for example involve the GtkTextBuffer/GeditDocument), you write this code in a separate file, and test the functions in that file with a unit-test tool.

In C with GLib there are g_test_*() functions to write unit tests. In Python you also have something similar if I remember correctly (but I’m not a Python expert :-/).

What I do is to write unit tests for stuff that can be easily unit-tested (and when writing new code, the code can be arranged to be easily unit-testable instead of being mixed with a lot of other unrelated code).

Example with libgedit-amtk, it has a tests/ directory with unit-tests/ and interactive-tests/ subdirs. The interactive tests are there to test a specific part of the GUI, more easily and more thoroughly than when it’s integrated in an entire app (for instance when a hard-to-reproduce error is triggered, a GUI widget is shown in the real app; with an interactive test you can add a button that - when clicked - shows that GUI widget as if the error occurred).

Other GNOME apps are more and more using a tool called openQA (search this term here on Discourse, there are regularly status updates on the progress made). But gedit doesn’t use it.

It seems you are more interested to have end-to-end or integration tests. That’s a bit more difficult to achieve with GTK (except with openQA, as I understand it).

So the easy approach is what I described above. openQA for gedit might be a solution for what you’re looking for.

6

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.