Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/kcmvp/archunit
Golang Architecture Test Framework
https://github.com/kcmvp/archunit
architecture architecture-test easy-to-use onion-architecture
Last synced: 12 days ago
JSON representation
Golang Architecture Test Framework
- Host: GitHub
- URL: https://github.com/kcmvp/archunit
- Owner: kcmvp
- License: apache-2.0
- Created: 2023-11-21T02:22:06.000Z (almost 1 year ago)
- Default Branch: main
- Last Pushed: 2024-06-18T02:05:10.000Z (5 months ago)
- Last Synced: 2024-06-21T20:31:55.113Z (5 months ago)
- Topics: architecture, architecture-test, easy-to-use, onion-architecture
- Language: Go
- Homepage:
- Size: 171 KB
- Stars: 4
- Watchers: 1
- Forks: 0
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
Architecture Test Framework For Go Project
## What is ArchUnit
ArchUnit is a simple and flexible extensible library for checking the architecture of Golang project.
with it, you can make your project's architecture visible, testable and stable by setting a set of predefined architectural rules.
## Why architecture test matters?
1. **Maintaining architectural integrity**: Architecture tests help ensure that the intended architectural design and principles are followed throughout the development process. They help prevent architectural decay and ensure that the system remains consistent and maintainable over time.
2. **Detecting architectural violations**: Architecture tests can identify violations of architectural rules and constraints. They help catch issues such as circular dependencies, improper layering, or violations of design patterns. By detecting these violations early, developers can address them before they become more difficult and costly to fix.
3. **Enforcing best practices**: Architecture tests can enforce best practices and coding standards. They can check for adherence to coding conventions, naming conventions, and other guidelines specific to the architectural style or framework being used. This helps maintain a consistent codebase and improves code quality.
4. **Supporting refactoring and evolution**: Architecture tests provide confidence when refactoring or making changes to the system. They act as a safety net, ensuring that the intended architectural structure is not compromised during the refactoring process. This allows developers to make changes with more confidence, knowing that they won't introduce unintended side effects.
5. **Facilitating collaboration**: Architecture tests serve as a form of documentation that communicates the intended architectural design to the development team. They provide a shared understanding of the system's structure and help facilitate collaboration among team members. Developers can refer to the tests to understand the architectural decisions and constraints in place.
## Features
- This project implements the principles of [Hexagonal architecture](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)), which has been proven best practice of software architecture.You can easily apply rules with below aspects
- [Common Rules](#common-rules)
- [Lay Rules](#lay-rules)
- [Package Rules](#package-rules)
- [Type Rules](#type-rules)
- [Method Rules](#functionmethod-rules)
- [File Rules](#source-file-rules)
- Fully tested and easy to use, it can be used with any other popular go test frameworks.
- **NRTW(No Reinventing The Wheel)**. Keep using builtin golang toolchain at most.
## How to Use
1. Import the library
```go
go get github.com/kcmvp/archunit
```
2. Write a simple test
```go
func TestAllPackages(t *testing.T) {
pkgs := AllPackages().packages()
assert.Equal(t, 12, len(pkgs))
err := AllPackages().NameShouldBeSameAsFolder()
assert.NotNil(t, err)
}
```
> It's better to keep all the architecture tests in one file
## Rules
### Common Rules
1. PackageNameShouldBeSameAsFolderName
2. PackageNameShouldBe
3. SourceNameShouldBe
4. MethodsOfTypeShouldBeDefinedInSameFile
5. ConstantsShouldBeDefinedInOneFileByPackage
### Lay Rules
1. ShouldNotReferLayers
2. ShouldNotReferPackages
3. ShouldOnlyReferLayers
4. ShouldOnlyReferPackages
5. ShouldBeOnlyReferredByLayers
6. ShouldBeOnlyReferredByPackages
7. DepthShouldLessThan
### Package Rules
### Type Rules
### Function(Method) Rules
### Source File Rules