Types of Environment

What is Environment?

It is basically a server which hosts the application. There are basically three types of environment-

1.Development Environment - This is the environment where developer tests code and checks whether the application run successfully with that code. Every developer run his/ her machine that is called local environment. Once the application has been tested and developer feels that the code is working fine. Then application goes to test environment which is an independent server.


2.Test environment - The application is tested to check the reliability and to make sure it does not fail on the actual production server. Once QA finds any bug or defect, the application sends back to the developer to fix the bugs.This process is repeated until application is debug free and ready to deploy.


3. Production Environment - Once the application is approved by developer and QA , then it is deployed to the production Environment. After deployment finishes, all features and fixes are to be tested that they work properly in production. Basically testing is done in all environments. Test scripts are written once to run against all the environments.

Contract Testing

 Contract testing- 

The contract is between a consumer (for example, a client who wants to receive some data from an app) and a producer (for example, an API on a server that provides the data the client needs) 

Contract testing is a way to ensure that services can communicate between Producers and Consumers. 

Before making changes in service Producer needs to know if the consumer can still use the service and whether the changes still meet the demands of the consumer’s contract. This is when contract testing plays important role. 

Contracts are written and managed exclusively by consumers, producers must first obtain permission from consumers before they can make any changes. If producers need to implement new features, they can see which consumers would be affected by the change(s) by looking at the status of the consumer’s contract tests.

Swagger Spec

What is Swagger Spec -

Swagger allows us to describe the structure of an APIs so that machines can read them. The Swagger specification defines a set of files required to describe such an API. These files can then be used by the Swagger-UI project to display the API . The OpenAPI Specification, originally known as the Swagger Specification, is a specification for machine-readable interface files for describing, producing, consuming, and visualizing RESTful web services. Swagger definitions can be written in JSON or YAML format. 

Basic features of Swagger spec-

• It  provides Nice fancing UI generic operation. When creating an APIs, Swagger tool may  be used to automatically generate an Open API document based on the code itself.
• It reduces the need for human generated client code.
• Swagger open-source tooling may be used to interact directly with the API through the Swagger UI.
• It's human readable and machine readable. 

API

What is an API? 

API acts as an interface between two different applications so that they can communicate with each other and third-party vendors can write programs that interface easily with other programs. For example, two applications written in C# and Java can communicate via API. 

How Web Service is different from API? 

Web service and API both are means of communications. The only difference is that a Web service provides interaction between two machines over a network. “HTTP” is the most commonly used protocol for communication. Web service also uses REST, Soap, GraphQL and RPC as a means of communication. While an API can use any means of communication. For example- Jar files, Interrupts in Linux kernel API, DLL files in C/C# etc.

How does API work?

Imagine a waiter in a restaurant. You, the customer, are sitting at the table with a menu of choices to order from, and the kitchen is the provider who will fulfill your order.

You need a link to communicate your order to the kitchen and then to deliver your food back to your table. It can’t be the chef because he/she is cooking in the kitchen. You need something to connect the customer who’s ordering food and the chef who prepares it. That’s where the waiter — or the API — enters the picture.

The waiter takes your order, delivers it to the kitchen, telling the kitchen what to do. It then delivers the response, in this case, the food, back to you. 

 

Here are some key points to remember- 

1. API and Web service serve as a means of communication.
2. All Web Services are API but APIs are not Web Services. A Web Service needs a network for its operation whereas an API doesn’t need a network for its operation.
3. Web Service might not perform all the operations that an API would perform.
4. Web services include any software, application, or cloud technology that provides standardised web protocols (HTTP or HTTPS) to interoperate, communicate, and exchange data messaging written in different language formats – usually XML, Json Format, HTML, JavaScript – throughout the internet.

What are the Different Protocols for API? 

1. SOAP- SOAP is defined as Simple Object Access Protocol. This web service protocol exchanges structured data using XML and generally HTTP and SMTP for transmission.
Pros: Usually easier to consume, more standards, distributed computing
Cons: Difficult set-up, more coding, harder to develop
2. REST- (Representational state transfer)A REST web service uses HTTP and supports/repurposes several HTTP methods: GET, POST, PUT or DELETE. It also offers simple CRUD-oriented services.
Pros: Lightweight, human readable, easier to build
Cons: Point-to-point communication, lack of standards
3. GraphQL- It can show the best performance when the number of queries needs to be reduced to the absolute minimum. It can be a good solution for cases when there is no dependency between the client application and the server.
4. RPC- This protocol specifies the interaction between client-server based applications. One program (client) requests data or functionality from another program (server), located in another computer on a network, and the server sends the required response.
HTTP Methods for Restful APIs-

HTTP Verb
CRUD
Entire Collection
Specific Item (e.g. /customers/{id})

POST
Create
201 (Created), 'Location' header with link to /customers/ {id} containing new ID.
404 (Not Found), 409 (Conflict) if resource already exists.

GET
Read
200 (OK), list of customers. Use sorting and filtering to navigate big lists.
200 (OK), single customer. 404 (Not Found), if ID not found or invalid.

PUT
Update/Replace
405 (Method Not Allowed), unless you want to update/replace every resource in the entire collection.
200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.

DELETE
delete
405 (Method Not Allowed), unless you want to delete the collection itself.
200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid. 

for example--

Resource - Person

Service- Contact information 

Representation: name, address, Phone number 

JSON or XML format

Some of the risks using API-

API changes - we can risk about versioning, Structure - schema can change, Server calculations change.

Availability - Any n/w issue can have an effect how API works 

Performance-  Programmatic access , Security

We have to figure out different paths in API

Test doubles- we actually test that is not real. 

what are they ?

Mock - u can focus on testing , i have created json data , u can reference them in that way.

stubs - 

fake -

Anything that stands in for another part of the system 

Powerful tool 

why use them?

Isolate the server 

Server not available 

exploration means finding new things ..............

automation - repeating things - do not change , do change , third party API 

they are related but not same.

Automation approaches 

- 

Data Driven testing- what data is available . for example- how to share data bt 300 calls. 

Workflow driven- series of API call in seq

follow workflow as customer follow

setting up test automation.

there is new set of test data 

how data is effectively into coding

do not  automate everything

API are great way for automation testing

load testing, speed testing how fast page response, how many item page is looking for

security testing - 

the user suspects 

Standard security checks 

Areas of responsibilities

Vulnerabilities happens 

Validations 

Test micro services -

API driven 

 how do micro services talk to each other