Run the conformance harness¶

The compiler checks that your provider has the right methods. It cannot check that those methods behave the way a consumer relies on — that a read-only config yields nothing to post through, that Close is safe twice, that the capabilities you declare are the ones you have.

RunProviderConformance checks that, and it runs without a network.

Add it to your provider's tests¶

package myplatform_test

import (
    "testing"

    chatplatform "gitlab.com/phpboyscout/go/chat-platform"
    chatplatformtest "gitlab.com/phpboyscout/go/chat-platform/test"
    myplatform "gitlab.com/phpboyscout/go/chat-platform-myplatform"
)

func TestConformance(t *testing.T) {
    t.Parallel()

    chatplatformtest.RunProviderConformance(t, chatplatformtest.ConformanceConfig{
        NewProvider: func(cfg chatplatform.Config) (*chatplatform.Provider, error) {
            return myplatform.New(cfg)
        },
        Capabilities: chatplatformtest.Capabilities{
            Moderator:       true,
            MemberInspector: true,
            Interactive:     true,
            Commands:        true,
        },
        Space:          "1531227937678954747",
        AllowedChannel: "1531227938622800055",
    })
}

Space and AllowedChannel must be syntactically valid identifiers for your platform. They are never dialled — the harness only needs values your constructor will accept.

Declare capabilities honestly¶

Capabilities exists so the harness can tell "correctly does not offer this" apart from "should and does not". It is checked in both directions:

• Claim one you lack, and the harness looks for something impossible.
• Omit one you have, and it tells you — a capability nobody declares is a capability nobody discovers.

Why it runs offline¶

Because it has to run in CI, on a fork, and on a laptop with no credentials.

That constraint is load-bearing rather than a convenience, and it is worth stating plainly: if your provider cannot be constructed without a real token, it cannot be conformance-tested. The Discord provider failed its very first run for exactly this reason, and the fix was to move client construction out of New and into Connect — which is a better contract anyway. See Author a provider.

What belongs elsewhere¶

Behaviour needing a live platform — that a thread is really created, that the allowlist really filters an inbound feed, that a dropped connection really resumes — belongs in your own integration tests, gated behind an environment variable or a build tag.

The chat-platform-discord module keeps its forced-disconnect regression test behind an integration build tag for this reason: it cuts a real TCP connection and needs live credentials, so it is run locally and before a release rather than on every merge.

Reading a failure¶

Failures are reported as method: message. Treat one as a finding about your provider before you treat it as one about the harness.

On the Discord provider's first run the harness reported that the provider could not be constructed at all, and that an implemented capability was not declared. Both were real.