Submission declined on 28 June 2024 by OnlyNano (talk).
Where to get help
How to improve a draft
You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Editor resources
|
Submission declined on 3 June 2024 by Relativity (talk). This draft's references do not show that the subject qualifies for a Wikipedia article. In summary, the draft needs multiple published sources that are: Declined by Relativity 5 months ago.
|
Submission declined on 31 May 2024 by Hey man im josh (talk). This submission is not adequately supported by reliable sources. Reliable sources are required so that information can be verified. If you need help with referencing, please see Referencing for beginners and Citing sources. Declined by Hey man im josh 5 months ago. |
- Comment: Most of the sources in this draft are not reliable, such as medium (which is not reliable per WP:MEDIUM), and the pactflow.io source is a blog, which is not going to be as reliable. Relativity ⚡️ 21:54, 3 June 2024 (UTC)
Contract testing is a type of software testing.
The basic aim of contract testing is to ensure that software modules that communicate by exchanging messages, typically over HTTP or message queues, agree on the form that such messages must adhere to.
Contract testing complements other form of software testing, such us unit testing, integration testing or end-to-end testing[1]. Its main aim is to reduce the amount of end-to-end testing by ensuring that message exchange will be successful. It does not replace end-to-end functional testing as contract testing is only concerned with the form of the exchanged messages and not with the result of processing those messages.
Contract testing entities
editContract testing identifies three participants in the testing flow:
- The Consumer: in a HTTP exchange identifies the module performing the HTTP call. In queue messaging it identifies the consumer of messages from the queue.
- The Provider: in a HTTP exchange identifies the module receiving the HTTP call. In queue messaging identifies the publisher of events to the queue.
- The Broker: a centralised contract testing specific app to which all consumers and provides refer to to store and retrieve the contract files produced during contract testing.
Contract testing approaches
editThere are three basic approaches to contract testing[2]
- Consumer-Driven Contract Testing (CDCT or CDC): in this approach the Consumer initiates the test flow by mocking the provider and publishing to the Broker the contract file produced during the testing.
- Provider-Driven Contract Testing (PDCT or PDC): in this approach the Provider initiates the test flow by publishing to the Broker the contract it fulfils. Consumers will then verify if they adhere to it.
- Bidirectional Contract Testing (BDCT): in this approach any of the two ends, Consumer of Provider, can initiate the test flow by publishing their version of the contract to the Broker. Once both contracts involved in an interaction have been published, it is the Broker that will verify if they match.
Contract testing flow
editA typical flow for testing a HTTP interface in a Consumer-Driven Contract Testing [3] would be:
- The Consumer creates a test where the Provider module is mocked using a contract testing library. When the test is run, the consumer generates the message it intends to send to the producer and defines the responses it expects.
- When the Consumer test is executed, typically during a build pipeline, the contract testing mock library records all HTTP interactions in a file, called "contract", containing all received payloads and expected responses.
- The Consumer pipeline publishes the contract file to the Broker
- The Provider creates a test using a contract testing library which will download the contract from the Broker and replay all interactions contained in the contract against the Provider's HTTP endpoints.
- The Provider communicates to the Broker the outcome of the test indicating if the expected responses for each request in the contract could be produced.
If the Provider reports a success the two modules can be confident that they can communicate over HTTP interface for the endpoints considered in the contract testing.
Typically, the Broker will provide methods to get information on contract verification allowing pipelines to decide if a given version of a Consumer or Provider is suitable for deployment or if the deployment must be halted due a contract mismatch.
- in-depth (not just passing mentions about the subject)
- reliable
- secondary
- independent of the subject
Make sure you add references that meet these criteria before resubmitting. Learn about mistakes to avoid when addressing this issue. If no additional references exist, the subject is not suitable for Wikipedia.