geary/test
Niels De Graef 9acf5d344d Make Geary DBus-activatable. Bug 775956.
* org.gnome.Geary.service.in: create, and let it be installed by CMake.

* org.gnome.Geary.desktop.in: add `DBusActivatable=true`.

* geary-autostart.desktop.in: use `--gapplication-service` instead of
hidden.

* Change the way arguments are parsed:
  * Use the _command-line_ and _handle-local-options_ signals instead
    of _local-command-line_.
  * Remove the `--hidden` option (replaced by `--gapplication-service`)
  * Use VariantDict (which is a little cleaner)
  * Don't use global variables in Arg, but set them in
  the config instead.
  * We can no longer set a global summary due to the new option handling
  in GApplication. On IRC, I got the feedback that info like this should
  be going into a manpage.

* Since the QUIT-action can now be called without ever activating the
app, make the necessary changes to the `GearyController`:
  * `main_window` and `current_conversations` can be null.
  * use `pending_mailtos()` for the compose action as well.
  * Don't update the UNDO action if we're closing down.

* More instance variables prefixed with this (we're changing the lines
anyway, might as well do it properly).

* `Environment.set_prgname()` is already executed in GApplication.run(),
so no more need for `GearyApplication.PRGNAME`.

Signed-off-by: Niels De Graef <nielsdegraef@gmail.com>
2019-04-12 22:04:56 +10:00
..
client Make Geary DBus-activatable. Bug 775956. 2019-04-12 22:04:56 +10:00
data Add a unit test for upgrading an actual Geary v0.6 database. 2018-05-19 14:55:19 +10:00
engine Fix ConversationMonitor sometimes not loading more from remote 2019-04-04 16:57:53 +11:00
integration/imap Update Imap.ClientSession now IMAP NO commands aren't treated as errors 2019-04-01 02:01:04 +11:00
js Fix signature not being updated when composer first opened without one 2019-03-11 12:19:57 +11:00
meson.build Add new generic LRU cache to the client 2019-04-08 10:26:04 +10:00
mock-object.vala Add a mock object mixin that can check call expectations on mocks. 2018-04-07 10:02:18 +10:00
README.md Add initial integration test famework and IMAP client session tests 2019-03-31 02:05:14 +11:00
test-case.vala Add TestCase.async_complete_full method to avoid requiring a lambda 2019-03-31 01:29:52 +11:00
test-client.vala Add new generic LRU cache to the client 2019-04-08 10:26:04 +10:00
test-engine.vala Merge branch 'wip/remove-ci-test-workaround' into 'mainline' 2019-04-09 16:16:10 +00:00
test-integration.vala Add initial integration test famework and IMAP client session tests 2019-03-31 02:05:14 +11:00

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.