Package com.arc_e_tect.gradle.doppelganger.scan


package com.arc_e_tect.gradle.doppelganger.scan
  • Classes
    Class
    Description
    ContractVerificationSource for the Atlassian OpenAPI request validator: a test method whose call chain contains either .filter(new OpenApiValidationFilter(...)) (REST Assured style) or a direct .validateRequest(...) / .validateResponse(...) call, paired with a REST-Assured-style request built via given()...when()...get(...) calls in the same method.
    Resolves the path portion of an OpenAPI root document's first servers[].url entry, e.g.
    ContractVerificationSource for Spring RestDocs, recognising three independent call-chain shapes for the same underlying convention - a request-builder call paired with a document(...) call somewhere in the same method body: spring-restdocs-mockmvc: mockMvc.perform(get(...)/post(...)/put(...)/ delete(...)/patch(...)) together with .andDo(document(...)). spring-restdocs-webtestclient: webTestClient.get()/post()/put()/ delete()/patch().uri(...).exchange()...consumeWith(document(...)) - the HTTP verb comes from the request-builder method and the path from the uri(...) call. spring-restdocs-restassured: given(...).filter(document(...))... when().get(...)/post(...)/put(...)/delete(...)/patch(...) - the verb call directly scoped on a call named when.
    ContractVerificationSource for Spring Cloud Contract: declarative contract DSL files under src/testContract/resources/contracts/**/*.groovy (and .yml), read structurally for method '...' and url '...' / urlPath '...' entries.
    Best-effort detection of the HTTP status code a test method asserts, from the same List<MethodCallExpr> a ContractVerificationSource AST scanner already collects for that method - not exhaustive, since a test can assert a response's status in ways this cannot recognise (a variable, a helper method, a custom matcher); such tests still count towards an endpoint's overall contract test count, they simply contribute no evidence to any specific response code's count.