81859bd3c3
`GLib.TestSuite` is a special type of object, as it doesn't actually
have an associated copy function or a reference/unreference function.
In practice, that actually means there's no way to actually have 2
strong references to such an object, or to copy it somehow. Due to the
way GObject properties in Vala work, that means you can't really use
them either.
Ever since vala commit 5f0a146f65, this got reflected properly in the
internally maintained GLib VAPI (as people were experiencing double
frees otherwise), but it was added only conditionally for GLib 2.70 or
later. In practice, that means you only get vala compiler issues if you
(impliclty) set `--target-glib=2.70` (or a later version).
To fix this for vala-unit and our own Geary tests, this commit changes
the `ValaUnit.TestCase` class to only allow "stealing" the strong
reference to the `GLib.TestSuite`, rather than somehowing allowing
people to hold a weak reference, and by also making it a protected field
rather than a property.
Since this changes the API of ValaUnit, we also bump the version. In
general though, I hope people aren't using ValaUnit externally, since
these types of API/ABI breaks can happen with Vala libraries.
Link:
|
||
|---|---|---|
| .. | ||
| client | ||
| data | ||
| engine | ||
| integration | ||
| js | ||
| mock | ||
| meson.build | ||
| README.md | ||
| test-case.vala | ||
| test-client.vala | ||
| test-engine.vala | ||
| test-integration.vala | ||
| test-js.vala | ||
| test-server.vala | ||
Automated Test Infrastructure
Geary currently supports three types of automated tests:
- Engine unit tests
- Client (GTK and JavaScript) unit tests
- Server integration tests
Unit tests
Unit tests test individual functions, in general avoid doing any I/O so they are fast, and can be run automatically.
The engine and client unit tests are hooked up to the Meson build, so you can use Meson's test infrastructure to build and run them. These are run automatically as part of the Gitlab CI process and if you use the development Makefile, you can execute them locally by simply calling:
make test
The engine tests can be run headless (i.e. without an X11 or Wayland session), but the client tests require a functioning display since they execute GTK code.
Integration tests
Integration tests run Geary's network code against actual servers, to ensure that the code also works in the real world.
The integration tests are built by default, but not currently hooked up to Meson and are not automatically run by Gitlab CI, since they require multiple working servers, network connection to the servers, and login credentials.
You can run them manually however against any server you have a test account on, using the following form:
build/test/test-integration PROTOCOL PROVIDER [HOSTNAME] LOGIN PASSWORD
For example, to test against GMail's IMAP service:
build/test/test-integration imap gmail test@gmail.com p455w04d
If PROVIDER is other, then HOSTNAME is required.
The easiest way to test against a number of different servers at the moment is to create a test account for each, then write a shell script or similar to execute the tests against each in turn.