Renamed qontract to specmatic everywhere

craigastill · Mar 21, 2021 · 415376a · 415376a
1 parent ed54aa5
commit 415376a
Show file tree

Hide file tree

Showing 21 changed files with 204 additions and 204 deletions.
diff --git a/Features.md b/Features.md
@@ -28,7 +28,7 @@ Specmatic supports the contract testing of Kafka messages. A contract describes
 
 ## Test Mode
 
-In test mode, Qontracts accepts a contract file, and the hostname and port of the service whose API is being tested. It then sends an HTTP request based on the request format described in the contract for every scenario, generating random values where no examples are given. When the service responds, it validates the response based on the format in the contract.
+In test mode, Specmatics accepts a contract file, and the hostname and port of the service whose API is being tested. It then sends an HTTP request based on the request format described in the contract for every scenario, generating random values where no examples are given. When the service responds, it validates the response based on the format in the contract.
 
 This is meant to be used by API providers.
 

diff --git a/_includes/authoring_contract_introduction.md b/_includes/authoring_contract_introduction.md
@@ -1,4 +1,4 @@
-Copy paste below text into a file with name "service.qontract". This, as you can see, uses the Gherkin syntax to describe a basic GET request. 
+Copy paste below text into a file with name "service.spec". This, as you can see, uses the Gherkin syntax to describe a basic GET request. 
 
     Feature: Contract for the petstore service
 

diff --git a/_includes/setup_command_line.md b/_includes/setup_command_line.md
@@ -1,19 +1,19 @@
 Download the standalone Jar.
 
-<https://github.com/znsio/specmatic/releases/download/{{ site.latest_release }}/qontract.jar>
+<https://github.com/znsio/specmatic/releases/download/{{ site.latest_release }}/specmatic.jar>
 
 #### Mac / Linux
 
 ```
-alias qontract='java -jar <basedir>/qontract.jar'
+alias specmatic='java -jar <basedir>/specmatic.jar'
 ```
 
 #### Windows
 
 Create a batch file with below content.
 
 ```
-java -jar <basedir>/qontract.jar %*
+java -jar <basedir>/specmatic.jar %*
 ```
 
 The %* portion tells the batch script to pass all of the parameters it receives to the new command.
diff --git a/documentation.md b/documentation.md
@@ -5,7 +5,7 @@ nav_order: 1
 ---
 # A Contract Driven Development Tool
 
-[Get started now](/getting_started.html){: .btn .btn-primary .fs-5 .mb-4 .mb-md-0 .mr-2 } [View it on GitHub](//github.com/znsio/qontract){: .btn .fs-5 .mb-4 .mb-md-0 }
+[Get started now](/getting_started.html){: .btn .btn-primary .fs-5 .mb-4 .mb-md-0 .mr-2 } [View it on GitHub](//github.com/znsio/specmatic){: .btn .fs-5 .mb-4 .mb-md-0 }
 
 [![Maven Central](https://img.shields.io/maven-central/v/in.specmatic/specmatic-core.svg)](https://mvnrepository.com/artifact/in.specmatic/specmatic-core) [![GitHub release](https://img.shields.io/github/release/znsio/specmatic.svg)](https://github.com/znsio/specmatic/releases) ![CI Build](https://github.com/znsio/specmatic/workflows/CI%20Build/badge.svg) [![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=znsio_specmatic&metric=alert_status)](https://sonarcloud.io/dashboard?id=znsio_specmatic) [![Twitter Follow](https://img.shields.io/twitter/follow/specmatic.svg?style=social&label=Follow)](https://twitter.com/specmatic)
 ---

diff --git a/documentation/Versioning.md b/documentation/Versioning.md
@@ -76,15 +76,15 @@ Here's a sample git repository that contains the math contract:
 ```
 <BASE_DIR>
     /run
-        /qontract
+        /specmatic
             /examples
-                math_1.qontract
-                math_2.qontract
+                math_1.spec
+                math_2.spec
 ```
 
-- The path ./run/qontract/examples acts as a namespace, much like a dot separated package name.
+- The path ./run/specmatic/examples acts as a namespace, much like a dot separated package name.
 - Contract file names can begin with any text (no spaces)
-    - If there is a version number, then they must include version number at the end of the name before ".qontract" extension.
+    - If there is a version number, then they must include version number at the end of the name before ".spec" extension.
     - The underscore separates the name of the contract and version number
     - In above example the name of contract is math and there are two versions of this API.
 
@@ -98,12 +98,12 @@ Since the file is in git, comparing it with its previous version is easy.
 
 Let's say you have the git repo in your home directory with the directory structure mentioned above.
 
-Make a change to math_1.qontract.
+Make a change to math_1.spec.
 
-To check if the change is backward compatible, open a terminal or command prompt and run the command `java -jar qontract.jar compatible git file ./run/qontract/examples/math_1.qontract`. You should see something like this if the change is backward compatible:
+To check if the change is backward compatible, open a terminal or command prompt and run the command `java -jar specmatic.jar compatible git file ./run/specmatic/examples/math_1.spec`. You should see something like this if the change is backward compatible:
 
 ```shell
-> java -jar qontract.jar compatible git file ./run/qontract/examples/math_1.qontract
+> java -jar specmatic.jar compatible git file ./run/specmatic/examples/math_1.spec
 Tests run: 1, Passed: 1, Failed: 0
 
 The newer contract is backward compatible
@@ -120,7 +120,7 @@ This is useful in CI.
 If you wish to compare the changes in a contract between two commits, such as HEAD and HEAD^1, try this:
 
 ```shell
-> java -jar qontract.jar compatible git commits ./remote/random.qontract HEAD HEAD^1
+> java -jar specmatic.jar compatible git commits ./remote/random.spec HEAD HEAD^1
 Tests run: 1, Passed: 1, Failed: 0
 
 The newer contract is backward compatible

diff --git a/documentation/authoring_contracts.md b/documentation/authoring_contracts.md
@@ -31,7 +31,7 @@ You could simply write the contract yourself. This is usually done when you don'
 
 ### The contract file
 
-A contract file contains a description of an API or a set of APIs using the [Specmatic language](/documentation/language.html). Contract files must have the extension `.qontract`.
+A contract file contains a description of an API or a set of APIs using the [Specmatic language](/documentation/language.html). Contract files must have the extension `.spec`.
 
 ### Stub files that accompany the contract file
 
@@ -41,15 +41,15 @@ Stub files accompanying a contract can be easily used by anyone referring to the
 
 Stub files must be placed in a directory with the same name as the contract file, suffixed with _data.
 
-For example, given a contract file named orderservice.qontract:
+For example, given a contract file named orderservice.spec:
 * create a directory named orderservice_data in the same directory as the contract file
 * put the stub files in that directory
 
 The resulting directory structure might look something like this:
 
 ```
 |
- \_ orderservice.qontract [file]
+ \_ orderservice.spec [file]
  \_ orderservice_data     [directory]
     |
      \_ placing_an_order.json [file]
@@ -85,13 +85,13 @@ File: customer_stub.json
 
 ### Convert the sample into a contract
 
-Now run the `qontract import stub` command on it:
+Now run the `specmatic import stub` command on it:
 
 ```bash
-> qontract import stub -o <qontract file>.json <stub file>.json
-Written to file /Users/xyz/customer_stub.qontract
+> specmatic import stub -o <specmatic file>.json <stub file>.json
+Written to file /Users/xyz/customer_stub.spec
 
-> cat customer_stub.qontract
+> cat customer_stub.spec
 Feature: New Feature
   Scenario: New scenario
     When GET /customer/name?id=(number)
@@ -108,11 +108,11 @@ The generated contract matches the sample.
 In fact we can use the [sample as a stub](/documentation/service_virtualisation.html). To do so:
 
 ```bash
-> mv customer_stub.qontract customer.qontract
+> mv customer_stub.spec customer.spec
 > mkdir customer_data
 > mv customer_stub.json customer_data
-> qontract stub customer.qontract
-Loading customer.qontract
+> specmatic stub customer.spec
+Loading customer.spec
   Loading stub expectations from /Users/joelrosario/tmp/customer_data
   Reading the following stub files:
     /Users/joelrosario/tmp/customer_data/customer_stub.json
@@ -133,7 +133,7 @@ Note the examples, which are used only when running [contract tests](documentati
 ## From an existing application using outbound proxy mode
 
 \
-![](/images/qontract-proxy.svg)
+![](/images/specmatic-proxy.svg)
 
 This tool will help you generate contract specs when the API exists in some environment and can be invoked.
 
@@ -144,7 +144,7 @@ As an example, let's generate a contract for the /employee API from this helpful
 First let's start the proxy:
 
 ```bash
-> qontract proxy ./contracts
+> specmatic proxy ./contracts
 Proxy server is running on http://localhost:9000. Ctrl + C to stop.
 ```
 
@@ -166,21 +166,21 @@ Finally, kill the proxy using Ctrl+C on the command prompt, and it will generate
 
 You will see something like this:
 ```bash
-Writing contract to ./data/new_feature.qontract
+Writing contract to ./data/new_feature.spec
 Writing stub data to ./data/stub0.json
 ```
 
 When it does, the proxy generates contracts and stubs out of all the request-response exchanges it has seen, and we will see something like this:
 
 ```bash
 > ls ./contracts
-new_feature.qontract stub0.json
+new_feature.spec stub0.json
 ```
 
 Let's see what's in them.
 
 ```bash
-> cat contracts/new_feature.qontract
+> cat contracts/new_feature.spec
 Feature: New feature
   Scenario: GET http://dummy.restapiexample.com/api/v1/employees
     Given type Data
@@ -336,7 +336,7 @@ And similarly, and improved stub file:
 ## From an existing application using reverse proxy mode
 
 \
-![](/images/qontract-reverse-proxy.svg)
+![](/images/specmatic-reverse-proxy.svg)
 
 If your remote service runs over HTTPS, use Inbound Proxy Mode. Specmatic acts as a transparent proxy between the client (Postman, your application, etc) and the API.
 
@@ -345,7 +345,7 @@ Let's use the same freely provided (again many thanks to its maintainer) test em
 ### Start the proxy
 
 ```bash
-> qontract proxy --target http://dummy.restapiexample.com ./contracts
+> specmatic proxy --target http://dummy.restapiexample.com ./contracts
 Proxy server is running on http://localhost:9000. Ctrl + C to stop.```
 ```
 
@@ -359,15 +359,15 @@ Finally, kill the proxy using Ctrl+C on the command prompt, and it will generate
 
 You will see something like this:
 ```bash
-Writing contract to ./data/new_feature.qontract
+Writing contract to ./data/new_feature.spec
 Writing stub data to ./data/stub0.json
 ```
 
 When it does, the proxy generates contracts and stubs out of all the request-response exchanges it has seen, and we will see something like this:
 
 ```bash
 > ls ./contracts
-new_feature.qontract stub0.json
+new_feature.spec stub0.json
 ```
 
 These files will look just like what is generated by the outbound proxy mode. So take a look at the previous section to see what is in them, and what to do once you have these files.
@@ -421,10 +421,10 @@ File: postman_employee.json
 ### Generate the contract
 
 ```bash
-> qontract import postman -o . <postman collection file>.json
+> specmatic import postman -o . <postman collection file>.json
 ```
 
-This command will read the Postman collection, and write the new qontract file into "qontract file.json" as specified in the command.
+This command will read the Postman collection, and write the new specmatic file into "specmatic file.json" as specified in the command.
 
 It will also output logs of the requests it made and responses it received.
 
@@ -433,7 +433,7 @@ The `-o .` option tells Specmatic to write the contract into the current directo
 Take a look at the resulting contract:
 
 ```gherkin
-> cat postman_employee-dummy.restapiexample.com.qontract
+> cat postman_employee-dummy.restapiexample.com.spec
 Feature: Free Test API
   Scenario: Employee data
     Given type Data

diff --git a/documentation/best_practices.md b/documentation/best_practices.md
@@ -9,8 +9,8 @@ Best Practices
 
 - [Best Practices](#best-practices)
   - [Design Patterns](#design-patterns)
-    - [All API endpoints in one .qontract file](#all-api-endpoints-in-one-qontract-file)
-    - [One API endpoint per .qontract file](#one-api-endpoint-per-qontract-file)
+    - [All API endpoints in one .spec file](#all-api-endpoints-in-one-specmatic-file)
+    - [One API endpoint per .spec file](#one-api-endpoint-per-specmatic-file)
     - [Multiple scenarios per endpoint](#multiple-scenarios-per-endpoint)
   - [Principles Of Design](#principles-of-design)
   - [Namespacing](#namespacing)
@@ -21,25 +21,25 @@ We have already covered how to author good [scenarios](/documentation/language.h
 
 ## Design Patterns
 
-### All API endpoints in one .qontract file
+### All API endpoints in one .spec file
 
 When all the endpoints are simple, data structures are not too deep, or the list of APIs is small, all the scenarios related to these end points can go into a single file.
 
 * Advantages
     * One single place to look at for all the APIs.
     * Common structures and datatypes that are declared in the Background section can be re-used across many scenarios.
 * Disadvantages / Smells
-    * The .qontract file can become large and becomes a scroll hell.
+    * The .spec file can become large and becomes a scroll hell.
     * All the developers update the same file, resulting in a larger number of merge conflics.
 
-### One API endpoint per .qontract file
+### One API endpoint per .spec file
 
 High complexity of API endpoints may result in too much information stuffed into a single contract file. This often happens when the data structures in the request or response payloads are very deep. When faced with such an API end point, put the definition of the API into a file by itself.
 
 * Advantages
-    * Easier to comprehend .qontract files
+    * Easier to comprehend .spec files
 * Disadvantages / Smells
-    * Common structures / datatypes across endpoints have to be duplicated (because we cannot import one .qontract file inside another)
+    * Common structures / datatypes across endpoints have to be duplicated (because we cannot import one .spec file inside another)
 
 ### Multiple scenarios per endpoint
 
@@ -144,7 +144,7 @@ Note how the [background](documentation/../language.html#background) contains ev
     * Reduces human error that can happen when there is duplication of structure or datatype definition across scenarios
 * Single Responsibility Principle
     * We recommend adhering to SRP in order to achieve well authored contracts.
-    * Each .qontract should have scenarios (regardless of whether they belong one endpoint or several endpoints) that are related to a single axis of change.
+    * Each .spec should have scenarios (regardless of whether they belong one endpoint or several endpoints) that are related to a single axis of change.
     * In other words, a contract file must change for one and only reason (entity, purpose or action).
     * This promotes healthy re-usability of structures and datatypes and helps in reducing merge conflicts
     * It may take time to triangulate on the right set of scenarios per file. In the long term this approach is best suited or applications of any size.
@@ -159,7 +159,7 @@ For example:
 /com
     /shop
         /orders
-            returns.qontract
+            returns.spec
 ```
 
 While this is not mandated, it is highly recommended as a way to improve maintainablity.
@@ -172,7 +172,7 @@ Static stub files should be co-located with their respective contracts. Example:
 /com
     /shop
         /orders
-            returns.qontract
+            returns.spec
             /returns_data
                 returns.json
 ```