Writing integration or unit (plugin) tests

Hey folks,

is there anything in place that helps with or some good example of writing tests for plugins? I have a slight idea how I want it to look like, but I figured I ask first. I don’t want to overlook anything and also I think it is a matter for a more generic debate on how to approach this.

Some background, you may want to skip the next paragraph…

Quite some time ago I started to write a plugin called csp for Caddy. It provides request scoped nonce values that are consumed by other request handlers that inject these values into the response body, as well as into the headers. Together this implements the Content-Security-Policy nonce attribute, This is in production on one of my servers and doing quite well. Actually I am a little proud how neat and performant it does its thing. Except I had a git rebase glitch or something and it stopped working. Unit tests still pass, but my integration tests that involve other middleware (template, browse) don’t, neither does the compiled server from the now unrecoverably broken source code. I can’t figure out what is wrong, because my integrations tests are a heap of spaghetti code (in contrast to my lovely crafted plugin itself). So redoing tests from scratch is what I want to do. Thanks for reading so far. :slight_smile:

… so my plugin csp depends on the header plugin, replaces stuff in the headers and provides its “service” to other plugins (I have patched browse and template) so they can inject nonce values into the response. My idea was to provide “some thing” as part of csp's public API that helps other plugin authors (and myself) to write tests that check the cooperation of all three plugins. Like providing some thing that takes your request handler and stacks it between the header handler, my csp handler and some response recorder handler, so you can check if the nonce is placed where you want it to be.

Stacking handlers, that’s what Caddy does already, i.e. there is an opportunity to leverage the mechanics that Caddy already provide and make it more wholesome leaning towards true integration testing. I’ve patched little bugs here and there in Caddy and each time looked at the surroundings of that code for some tests that I could extend and often there were simply none. That needs to change, right?

Ideas, hints, pointers anyone? :slight_smile:

Cheers,
Johannes

Using your CI suite (Gitlab-CI in my example):

  1. (Run the usual trivial tests, such as code style checking.)
  2. (Run the usual unit tests.)
  3. Actually build caddy, as if for a later deployment. Including your and all necessary plugins.
  4. Run integration tests with the artifact from (4):
    • Setup a clean, isolated, and new environment. (I start every integration test in its own container.)
    • Write a minimal configuration file.
    • Start caddy as background process. It will be the first.
    • Run all commands for the happy path. Check for errors-
    • … same for well-known undesired behaviour.
    • kill %1 — which terminates your first and only background process.
  5. (Deploy…)

This how it looks like for plugin upload:
https://hub.blitznote.com/src/caddy.upload/blob/6e9bf38e576ffae98b18bdb26de9d117fb8de8cc/.gitlab-ci.yml#L83-93
… and
https://hub.blitznote.com/src/caddy.upload/builds/504

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