gotify

The atago project wrote these specs on its own initiative and runs them in its own CI, to exercise atago against a real program. They are not gotify’s official test suite, and the gotify project is not affiliated with atago.

Summary #

1 suite · 3 scenarios

Contents #

gotify (self-hosted notification server) #

Gotify receives notifications and hands them back out. The full path is exercised against a real server on SQLite: an application is provisioned over the REST API, a message is pushed with that application’s token, and it is read back with admin credentials — so the message is proven to have been stored and served, not merely accepted.

The refusal matters as much as the delivery: pushing without valid credentials must fail rather than silently drop the notification.

One scenario goes further than JSON. The application’s icon is uploaded as a genuine multipart form-data request, downloaded back to disk, and verified as a real PNG — the same round trip a browser performs, asserted on the bytes that came back.

Source: test/e2e/thirdparty/gotify/gotify.atago.yaml Network policy: egress is allowed only to 127.0.0.1.

Scenario: the server reports health and version #

only when command -v gotify succeeds

Given #

  • Background service gotify is started: gotify.
  • Fixture file data/.keep is created.

When #

# HTTP GET /health via gotify
# HTTP GET /version via gotify

Then #

  • after HTTP GET /health:
    • HTTP status is 200
    • body at $.health equals green
  • after HTTP GET /version:
    • HTTP status is 200
    • body at $.version matches /^[0-9]+\.[0-9]+\.[0-9]+/

Scenario: an application pushes and the admin reads it back #

only when command -v gotify succeeds

Given #

  • Background service gotify is started: gotify.
  • Fixture file data/.keep is created.

When #

# HTTP GET /message via gotify2
# HTTP POST /application via gotify2
# capture ${app_token} from the response body
# HTTP POST /message via gotify2
# HTTP GET /message via gotify2

Then #

  • after HTTP GET /message:
    • HTTP status is 401
  • after HTTP POST /application:
    • HTTP status is 200
    • body at $.name equals atago-pipeline
  • after HTTP POST /message:
    • HTTP status is 200
    • body at $.title equals Deploy done
  • after HTTP GET /message:
    • HTTP status is 200
    • body at $.messages has length 1
    • body at $.messages[0].priority equals 5

Scenario: the app icon round-trips through a multipart upload #

only when command -v gotify succeeds

Given #

  • Background service gotify is started: gotify.
  • Fixture file data/.keep is created.
  • Fixture file icon.png is created.

When #

# HTTP POST /application via gotify3
# capture ${app_id} from the response body
# HTTP POST /application/${app_id}/image via gotify3
# capture ${image_path} from the response body
# HTTP GET /${image_path} via gotify3

Then #

  • after HTTP POST /application:
    • HTTP status is 200
  • after HTTP POST /application/${app_id}/image:
    • HTTP status is 200
    • body at $.image matches /^image//
  • after HTTP GET /${image_path}:
    • HTTP status is 200
    • image fetched-icon.png is png, width 1, height 1

Generated artifacts #

  • fetched-icon.png