Skip to content

Commit

Permalink
feat: add redis docs & glossary terms && pr template (#448)
Browse files Browse the repository at this point in the history
* fix: installation in docker with linux/wsl

Signed-off-by: Animesh Pathak <[email protected]>

* feat: add redis

Signed-off-by: Animesh Pathak <[email protected]>

* feat: add redis

Signed-off-by: Animesh Pathak <[email protected]>

---------

Signed-off-by: Animesh Pathak <[email protected]>
  • Loading branch information
Sonichigo authored Aug 26, 2024
1 parent cce86d8 commit a5c6373
Show file tree
Hide file tree
Showing 10 changed files with 150 additions and 64 deletions.
6 changes: 2 additions & 4 deletions .github/ISSUE_TEMPLATE/documentation-request.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,8 @@
---
name: Documentation request
about: Use this to propose information improvements and additions
title: "[ Documentation request ] "
labels: ''
assignees: ''

title: "[Docs]"
labels: '[Documentation]'
---

# Brief description
Expand Down
20 changes: 6 additions & 14 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,8 @@
# Pull Request Template
## What has changed?

## Description
Please include a summary of the change.

Please include a summary of the change. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes # (issue)
This PR Resolves #(issue)

## Type of change

Expand All @@ -13,22 +11,16 @@ Please delete options that are not relevant.
- [ ] Bug fix (non-breaking change which fixes an issue).
- [ ] New feature (non-breaking change which adds functionality).
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).
- [ ] This change requires a documentation update.
- [ ] Documentation update (if none of the other choices apply).

## How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

## Additional Context (Please include any Screenshots/gifs if relevant)
Please run npm run build and npm run serve to check if the changes are working as expected. Please include screenshots of the output of both the commands. Add screenshots/gif of the changes if possible.

...

## Checklist:

- [ ] My code follows the style guidelines of this project.
- [ ] I have performed a self-review of my own code.
- [ ] I have made corresponding changes to the documentation.
- [ ] I have added corresponding tests.
- [ ] Any dependent changes have been merged and published in downstream modules.

<!--- Thanks for opening this pull request! If the tests fail, please feel free to reach out to us by leaving a comment down below and we will be happy to take a look --->
<!--- Thanks for opening this pull request! If the tests fail, please feel free to reach out to us by leaving a comment down below and we will be happy to take a look --->
5 changes: 4 additions & 1 deletion src/components/Intro.js
Original file line number Diff line number Diff line change
Expand Up @@ -176,7 +176,10 @@ function Frameworks() {
</Link>
</li>
<li className="mt-5 flex flex-col space-y-3 text-lg">
<Link className="flex flex-col items-center justify-center space-y-1 p-6 text-center ">
<Link
to={useBaseUrl("/dependencies/redis")}
className="flex flex-col items-center justify-center space-y-1 p-6 text-center "
>
<img
className="h-8 w-8"
src="/docs/img/redis-logo.svg"
Expand Down
Original file line number Diff line number Diff line change
@@ -1,40 +1,92 @@
---
id: acceptance-testing
title: Acceptance Testing
title: Comprehensive Guide to Software Acceptance Testing
sidebar_label: Acceptance Testing
description: This glossary has an explanation of all the terminologies that beginners find difficult to understand at first glance.
description: Learn about Software Acceptance Testing, its types, benefits, and best practices. Discover how this final phase in the testing lifecycle ensures your software meets all user requirements before release.
tags:
- explanation
- glossary
keywords:
- API
- software testing
- UAT
- user acceptance testing
- software acceptance testing
---

### What is Acceptance Testing?
## What is Acceptance Testing?

Acceptance testing (AT) is a formal testing process that is conducted to determine whether a software system meets the
requirements of the customer or end user. AT is the last phase of software testing, and it is conducted after all other
levels of testing have been completed.
Acceptance testing (AT) is the final phase in the software testing life cycle, where the software is tested in a real-world environment by the customer or end user. The main objective is to ensure that the system meets all specified requirements and is ready for deployment. This stage is critical as it validates that the software is not only functional but also aligns with the user's needs and expectations.

The purpose of AT is to ensure that the software system is acceptable to the customer or end user. This means that the
system must meet the customer's or end user's needs and expectations. AT also helps to identify any defects or problems
with the software system that may have been missed during earlier phases of testing.
## Why is it important?

### Acceptance Testing Types:
Acceptance testing serves as a safety net before the software reaches the end users, minimizing the risk of post-release defects that could lead to costly fixes and user dissatisfaction.

- **User acceptance testing (UAT)**: This is the most common type of AT. It involves the customer or end user using the
software system in a way that simulates how they will use it in the real world.
- **Systematic testing**: This involves using a set of predetermined test cases to test the software system.
- **Acceptance test-driven development (ATDD)**: This is a technique that combines AT with test-driven development (TDD)
. TDD is a software development process that involves writing unit tests before the code is written. ATDD extends TDD
by adding acceptance tests to the mix.
## What Types of Acceptance Testing are there ?

### Benefits of Acceptance Testing:
There are several types of acceptance testing, each serving a unique purpose:

- It helps to ensure that the software system meets the needs and expectations of the customer or end user.
- It helps to identify any defects or problems with the software system that may have been missed during earlier phases of testing.
- It helps to improve the overall quality of the software system.
- It helps to reduce the risk of defects and problems with the software system.
- It helps to ensure that the software system is ready for release.
### User Acceptance Testing (UAT):

Acceptance testing is vital in ensuring software meets stakeholder demands and quality standards.
UAT is the most common form of acceptance testing, where real users test the software in an environment that mimics the production environment. The goal is to validate the software's functionality and usability from the end user's perspective.

Example: A financial institution might perform UAT on a new online banking system to ensure it meets user expectations before going live.

### Systematic Acceptance Testing:

This type involves using predefined test cases that cover all aspects of the system. It ensures that the software behaves as expected under various conditions.

Example: Systematic testing might involve running a series of transactions through an e-commerce platform to ensure it can handle different payment methods.

### Acceptance Test-Driven Development (ATDD):

ATDD combines acceptance testing with test-driven development (TDD). It involves writing acceptance tests before the actual development begins, ensuring that the final product meets the predefined acceptance criteria.

Example: A team developing a new feature for a mobile app might write acceptance tests first to ensure the feature will function correctly when completed.

## What are the Benefits of Acceptance Testing?

Acceptance testing offers numerous benefits that contribute to the overall success of a software project:

- Validates Requirements: Ensures that the software meets the agreed-upon requirements and expectations.
- Identifies Issues Early: Helps uncover defects that may have been missed during earlier testing phases, reducing the risk of post-release problems.
- Enhances Quality: Improves the overall quality of the software by ensuring it functions as intended.
- Reduces Risks: Minimizes the risk of releasing a flawed product, which can save time, money, and resources.
- Ensures Readiness: Confirms that the software is ready for deployment and will perform well in a production environment.
- Real-World Example: A major retailer might perform acceptance testing on its new inventory management system to ensure it can handle peak shopping seasons without issues.

## What are the Best Practices for Effective Testing ?

To ensure the effectiveness of acceptance testing, consider the following best practices:

- Involve Stakeholders Early: Engage key stakeholders early in the process to ensure their requirements are clearly understood and documented.
- Define Clear Acceptance Criteria: Establish clear and measurable acceptance criteria before testing begins to avoid ambiguity.
- Use Realistic Test Data: Use data that closely resembles real-world scenarios to better assess the software's performance.
- Automate Where Possible: While manual testing is crucial, automating repetitive tasks can save time and reduce human error.
- Iterate and Refine: Continuously refine the acceptance testing process based on feedback and testing outcomes.

## Conclusion

Acceptance testing is a critical step in the software development process, ensuring that the product is ready for deployment and meets the user's needs. By following best practices and involving key stakeholders, organizations can deliver high-quality software that satisfies customer expectations.

## FAQs

### What is the difference between UAT and Systematic Testing?

UAT focuses on testing the software from the end user's perspective, while systematic testing involves using predefined test cases to validate the software's functionality.

### Can acceptance testing be automated?

Yes, certain aspects of acceptance testing, such as repetitive test cases, can be automated to improve efficiency. However, manual testing is often necessary for user-centric tests.

### How does ATDD differ from traditional testing methods?

ATDD involves writing acceptance tests before development begins, ensuring that the software is built to meet specific acceptance criteria from the start.

### What role do stakeholders play in acceptance testing?

Stakeholders are involved in defining acceptance criteria and often participate in UAT to validate that the software meets their needs.

### How does acceptance testing fit into the overall testing process?

Acceptance testing is the final phase in the testing process, occurring after unit, integration, and system testing have been completed.
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
---
id: idempotency
title: Idempotent REST API
title: How Idempotent REST APIs Boost Reliability and Error Handling
sidebar_label: Idempotency
description: Optimize user experience with idempotent APIs. Ensure smooth interactions & error handling for satisfied users.
description: Discover how idempotent APIs enhance user experience, reliability, and error handling. Learn best practices for implementing and testing idempotent methods.
tags:
- explanation
- glossary
Expand All @@ -16,9 +16,11 @@ keywords:

## What is idempotency in the context of REST APIs?

Idempotency refers to the property of certain operations where applying them multiple times has the same effect as applying them once. In the realm of RESTful APIs, idempotency ensures that performing a request multiple times will not lead to different outcomes beyond the initial request. This property is crucial for ensuring reliability, consistency, and fault tolerance in distributed systems.
Idempotency means making multiple identical requests has the same effect as making a single request. In REST APIs, this ensures consistent and reliable interactions even with repeated requests.

### Examples of idempotent HTTP methods in RESTful APIs
Idempotent operations are essential for maintaining data integrity, error recovery, and fault tolerance in distributed systems.

### Examples of Idempotent HTTP Methods

Idempotency is often associated with specific HTTP methods in RESTful APIs:

Expand All @@ -28,14 +30,14 @@ Idempotency is often associated with specific HTTP methods in RESTful APIs:

![Methods](https://www.hubspot.com/hs-fs/hubfs/Google%20Drive%20Integration/Idempotent%20Api%20Draft-1.png?width=650&name=Idempotent%20Api%20Draft-1.png)

## How does idempotency ensure reliability in distributed systems?
## How Idempotency Ensures Reliability ?

In distributed systems, where network failures and message duplication can occur, idempotent operations ensure reliability by:

- **Preventing Duplicate Effects:** Even if a request is duplicated due to network issues or client retries, idempotent operations ensure that the system's state remains unchanged after the initial request.
- **Simplifying Error Recovery:** Idempotent APIs simplify error recovery mechanisms by allowing clients to retry requests without causing additional modifications or inconsistencies in the system.

### Best practices for implementing idempotent APIs
### Best Practices for Idempotent APIs

Implementing idempotent APIs involves adopting best practices such as:

Expand All @@ -44,19 +46,19 @@ Implementing idempotent APIs involves adopting best practices such as:
- **Request Idempotency Tokens:** Use request headers or tokens (e.g., UUIDs) to uniquely identify and handle idempotent requests to prevent duplication or unintended re-execution.
- **Idempotent Database Operations:** Implement database transactions and queries in a way that ensures data modifications are idempotent, even under concurrent or distributed execution scenarios.

### Challenges in implementing and testing idempotent APIs
### Challenges in Idempotent API Implementation

Implementing and testing idempotent APIs can pose challenges such as:

- **Ensuring Correctness Across Systems:** Guaranteeing idempotency in distributed systems with multiple interacting components requires careful design and coordination.
- **Handling Edge Cases:** Identifying and addressing edge cases where idempotency might be violated due to specific system behaviors or failure scenarios.
- **Testing for Idempotency:** Developing comprehensive test cases to verify that operations remain idempotent under various conditions, including network failures, concurrency, and system failures.

## Importance in Distributed Systems
## Why Idempotency is Important ?

Idempotency becomes particularly critical in distributed systems where network failures, message duplication, and out-of-order message delivery can occur. In such environments, ensuring that operations are idempotent helps prevent unintended side effects and ensures that the system can recover gracefully from failures without compromising data integrity.

### Why is idempotency important in RESTful APIs?
### Idempotency important in RESTful APIs

Idempotent APIs offer several benefits that contribute to the reliability, scalability, and consistency of systems. Here are some key advantages:

Expand Down Expand Up @@ -87,11 +89,9 @@ Idempotent APIs offer several benefits that contribute to the reliability, scala
9. **Cross-System Integration:**
Idempotent APIs facilitate integration with other systems and services. They provide a reliable and predictable way for different components to communicate, reducing the likelihood of synchronization issues and making it easier to design robust, interoperable systems.

## Idempotent vs Safe

The concepts of ‘idempotent methods’ and ‘safe methods’ are often confused. An operation is considered idempotent if applying it multiple times has the same effect as applying it once. In other words, subsequent executions of an idempotent operation do not produce different outcomes. This property is essential for ensuring consistency, fault tolerance, and reliable behavior in distributed systems.
## Idempotent vs Safe Methods

On the other hand, safe operations are those that do not modify the state of the system. Safe operations are read-only and do not have any side effects on the server. They can be repeated multiple times without changing the state of the resource. Therefore, all safe methods are idempotent, but not all idempotent methods are safe.
Idempotent operations yield the same result regardless of repetitions. Safe methods do not change the system state. All safe methods are idempotent, but not all idempotent methods are safe.

![Idempotent vs Safe](https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSNpJRr8DjkwYCknq1yp0PNVbGQ9Gy0rcBwtg&s)

Expand All @@ -103,36 +103,34 @@ Certainly! Here are 6 FAQs about idempotent REST APIs:

## Frequently Asked Questions

### 1. What does it mean for an HTTP method to be idempotent?
### What does it mean for an HTTP method to be idempotent?

An HTTP method is considered idempotent if making multiple identical requests with that method yields the same result as making a single request. This property ensures that repeating the operation does not have additional side effects beyond the initial request.

### 2. Why is idempotency important in RESTful API design?
### Why is idempotency important in RESTful API design?

Idempotency is crucial in RESTful API design for reliability and consistency. It allows clients to safely retry requests without causing unintended modifications or inconsistencies in the server's state. This property is essential for handling network issues, retries, and ensuring data integrity across distributed systems.

### 3. What are some examples of idempotent HTTP methods?
### What are some examples of idempotent HTTP methods?

Examples of idempotent HTTP methods include:

- **GET:** Retrieving a resource using GET multiple times returns the same resource state.
- **PUT:** Updating a resource with PUT results in the same state regardless of how many times it's applied.
- **DELETE:** Deleting a resource using DELETE remains unchanged if the resource is already deleted or does not exist.

### 4. How does idempotency contribute to error handling and fault tolerance?
### How does idempotency contribute to error handling and fault tolerance?

Idempotent APIs simplify error handling and fault tolerance by allowing clients to retry requests safely. If a request fails due to network issues or timeouts, clients can resend the request without worrying about introducing inconsistencies or unintended modifications in the server's state.

### 5. What practices should developers follow to ensure idempotency in API implementations?
### What practices should developers follow to ensure idempotency in API implementations?

To ensure idempotency in API implementations, developers should:

- Use appropriate HTTP methods like PUT and DELETE for operations that modify resources.
- Implement operations in a way that does not change the server's state if the request is repeated.
- Use request headers or tokens to uniquely identify and handle idempotent requests to prevent duplicate execution.

### 6. How can developers test for idempotency in REST APIs?
### How can developers test for idempotency in REST APIs?

Testing for idempotency involves creating test cases that simulate scenarios where requests may be duplicated or retried due to network failures or client retries. Developers should verify that repeating the same request does not result in different outcomes or unintended side effects in the system's state.

These FAQs provide insights into the concept of idempotency in RESTful APIs, its importance, implementation best practices, and testing considerations. Understanding idempotency is key to designing robust and reliable API systems that ensure consistent behavior and data integrity.
Original file line number Diff line number Diff line change
Expand Up @@ -78,6 +78,8 @@ Ensuring every code path is tested, especially in large systems, demands meticul

As code evolves, test cases must be updated, requiring ongoing coordination with development teams.

As code evolves, test cases must be updated, requiring ongoing coordination with development teams.

## Best Practices for Effective White Box Testing

1. **Collaboration with Developers**:
Expand Down
1 change: 1 addition & 0 deletions versioned_docs/version-2.0.0/dependencies/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,3 +7,4 @@ sidebar_label: Supported Dependencies
- [MongoDB](/dependencies/mongo/)
- [PostgresSQL](/dependencies/postgres)
- [HTTP](/dependencies/http)
- [Redis](/dependencies/redis)
Loading

0 comments on commit a5c6373

Please sign in to comment.