Namespace ProtoTest.Http
Classes
- AuthAttribute<TAuthenticator>
Applies an IProtoHttpAuthenticator to the HTTP-based clients of a test, for example
[Auth<BearerTokenAuthenticator>("token")]. Several attributes at the same level are ordered by Order and composed.
- ProtoApplicationTarget
Records which application a registered HTTP target (client) belongs to, so collectors and other services can resolve the target's application without a separate client configuration section.
- ProtoApplicationTargets
Resolves the application a registered target belongs to.
- ProtoCompositeHttpAuthenticator
Applies several authenticators in order, tracing each application under a shared source.
- ProtoHttpAssertions<TResponse>
The status-assertion facade an HTTP protocol exposes: HaveHttpStatus(HttpStatusCode) runs the protocol's assertion with the facade's polarity, so
ShouldandShouldNotread the same in every protocol.
- ProtoHttpAttachmentOptions
Options for capturing and redacting HTTP request/response artifacts, shared by the REST and GraphQL integrations so both observe the same capture and redaction rules. Each protocol registers an instance created with its own configuration section.
- ProtoHttpAuthLifecycleHook
Resolves the ordered authenticator attributes that apply to a protocol before each test, builds a composite authenticator when more than one applies, and records the resolved configuration as the protocol's auth entity state. The client a test uses is chosen separately by
[Application]. The state is stored under the protocol's key, so protocols sharing this hook never overwrite each other. A test's[SignedInAs]declaration rides along the winning authenticator set, because it names who the test acts as rather than how a request is authenticated.
- ProtoHttpAuthenticationApplier
Resolves and applies (or explicitly skips) authentication for one outgoing HTTP request, shared by every protocol request builder. The outcome is an attribute of the request operation the caller owns, not a separate entry: authentication is part of the request, not a step beside it.
- ProtoHttpAuthenticationContext
Context supplied to an HTTP-based authenticator when a request is sent.
- ProtoHttpClientInitializer
Initializes a named HTTP client from an explicit URL, or from the application the target belongs to: the application's base address, optionally combined with one of its named endpoint paths.
- ProtoHttpClientRegistration
Registers the named HTTP client and initializer shared by every HTTP-based protocol's
AddClientoverloads, so each protocol only supplies its own display label and error text.
- ProtoHttpClientResolution
The HTTP client a protocol accessor will use, together with the per-test resolver that supplies its base address and the names requests and traces should use.
- ProtoHttpClientResolver
Resolves the HTTP client a protocol accessor uses for the current test: the protocol's scoped client first, then a host- or user-registered client under the requested name, then a uniquely named client of the protocol from another application, then the application's in-process transport rooted at the endpoint the client registered.
- ProtoHttpContextState
Per-test HTTP protocol state: the authenticator the test's
[Auth]attributes resolved to and the request sequence attachment names use. One type keyed by protocol, so REST, GraphQL and any later HTTP protocol each keep their own instance without a state class per protocol.
- ProtoHttpDiagnosticSanitizer
Redacts sensitive values from HTTP request/response diagnostics before they are traced or attached. Shared by the REST and GraphQL integrations.
- ProtoHttpEndpoint
Shared resolution of the base address an HTTP-based client sends to.
- ProtoHttpExchange
The send-and-read mechanics every HTTP-based protocol shares: send with response headers read, cap the buffered body through ProtoHttpResponseBuffer, then read it as text and bytes. A failure while reading disposes the response, so a caller cannot leak one by forgetting a finally block; on success the caller owns Response.
- ProtoHttpExchangeResult
One completed exchange: the response the caller now owns, its text body and buffered bytes.
- ProtoHttpHeaders
Shared header application for HTTP-based integrations.
- ProtoHttpOptionsRegistration
Registers per-protocol response and attachment options under a stable protocol key, so REST and GraphQL keep their own configuration sections even though they share the base option types.
- ProtoHttpOptionsResolver
Resolves the response and attachment options a protocol registered under its own key, so REST and GraphQL never share configuration even though they use the same base option types. A protocol integration resolves its own options through these methods, matching the key it registered with ProtoHttpOptionsRegistration.
- ProtoHttpProtocolBuilder<TBuilder>
Shared fluent surface for the HTTP-based protocol builders: named and resolver-based clients, response options and attachment capture. A protocol supplies its key, its configuration sections and the label used when a client is registered under an application.
- ProtoHttpRequestBuilder<TResponse, TBuilder>
The state and fluent surface every HTTP-based request builder shares: the client, context, target, headers, authenticator resolution and base-address resolver, plus the hooks each protocol uses to record how its authentication and headers were configured. A protocol's request shape (a REST route, a GraphQL document) stays in the derived builder.
- ProtoHttpResponse
The shared half of an HTTP-based protocol response: the raw message and body, the execution context it was made in, the attachment naming state, the status assertion and disposal. A protocol derives from it and adds its own document model - REST adds binary and dynamic content, GraphQL the data/errors envelope - so a new HTTP-based integration starts from the same mechanics and keeps the same diagnostics contract.
- ProtoHttpResponseContext
The per-call state an HTTP-based protocol response carries: the execution context it was made in, the target and operation identity, attachment naming and the parent operation. One record instead of the long parameter lists every response constructor repeated.
- ProtoHttpResponseOptions
Controls how HTTP response bodies are buffered, shared by the REST and GraphQL integrations. Each protocol registers an instance created with its own configuration section.
- ProtoHttpUri
Platform-independent HTTP URI classification shared by protocol integrations.
- ProtoStatusAssertion
The status assertion HTTP and gRPC responses share. It records one operation and Checks section for either protocol, names the expected status through the caller's description, and lets the caller supply the failure its own exception type. One implementation is what keeps a status assertion reading the same in every trace.
- ProtoTargetBuilder
Shared, protocol-neutral IProtoTargetBuilder for every protocol integration.
- ProtoTestUser
The identity a test acts as: a name, roles and claims. Declare one per test with
[SignedInAs("alice", "admin")]or during the test body withcontext.SignIn(user); the identity lives in the test's execution context only, so it can never leak into the next test.
- ProtoTestUserClaim
One claim the built-in test user carries.
- ProtoTestUserExtensions
Publishes and reads the test's signed-in user.
- ProtoTestUserHeader
The wire form the built-in test user travels in: one
ProtoTest-Userheader (a gRPC call carries it asprototest-usermetadata) holding the identity as Base64-encoded JSON. The header is not a credential - it only names a test identity - and the app reads it through the shipped in-process authentication; an application that does not register it ignores the header.
- SignedInAsAttribute
Declares the user a test signs in as, for example
[SignedInAs("alice", "admin", "billing")]. The identity is published to the test's execution context (read it withcontext.SignedInUser()) and rides the existing HTTP auth lifecycle: REST, GraphQL and gRPC requests carry it to the application, and the protocol'sAuthentity names the declaration among its authenticators. The shipped app-side authentication (AddTestUserAuthenticationinProtoTest.AspNetCore) turns it into the application'sClaimsPrincipal; without an in-process application the shipped transport stays inert, the request is sent unchanged and theauth:userentity records the reason.
- TestUserAuthenticator
Sends the test's signed-in user to the application as the HeaderName header. The header is only meaningful to an application the run hosts in-process and whose suite registered the shipped app-side authentication; against a published application the authenticator is inert (the request is sent unchanged, and
SignInrecorded the reason on the auth entity).
Interfaces
- IProtoHttpAuthenticator
Authenticates an outgoing HTTP request for a REST, GraphQL, or other HTTP-based client.