Contributing to NetTraceX
Thank you for your interest in contributing to NetTraceX! This guide will help you get started with contributing to the project.
Getting Started
Prerequisites
- Go 1.21 or later
- Git
- Make (for Unix/Linux/macOS) or PowerShell (for Windows)
- A terminal emulator
Development Setup
-
Fork the repository
# Fork the repository on GitHub, then clone your fork
git clone https://github.com/your-username/nettracex-tui.git
cd nettracex -
Set up the development environment
# Add upstream remote
git remote add upstream https://github.com/nettracex/nettracex-tui.git
# Install dependencies
go mod download
go mod tidy -
Build the project
# Unix/Linux/macOS
make build
# Windows
go build -o bin/nettracex.exe ./cmd/nettracex -
Run tests
# Run all tests
go test ./...
# Run tests with coverage
go test -coverprofile=coverage.out ./...
go tool cover -html=coverage.out
Development Workflow
1. Create a Feature Branch
# Create and switch to a new branch
git checkout -b feature/your-feature-name
# Or for bug fixes
git checkout -b fix/your-bug-description
2. Make Your Changes
- Follow the existing code style and patterns
- Write tests for new functionality
- Update documentation as needed
- Ensure all tests pass
3. Test Your Changes
# Run the full test suite
go test ./...
# Run specific tests
go test ./internal/domain -v
go test ./internal/tools/ping -v
# Run with race detection
go test -race ./...
# Run with coverage
go test -cover ./...
4. Commit Your Changes
# Stage your changes
git add .
# Commit with a descriptive message
git commit -m "feat: add new diagnostic tool for network latency"
5. Push and Create a Pull Request
# Push your branch
git push origin feature/your-feature-name
Then create a pull request on GitHub.
Code Style and Standards
Go Code Style
- Follow the Effective Go guidelines
- Use
gofmtto format your code - Use
golintto check for style issues - Use
go vetto check for potential issues
# Format code
go fmt ./...
# Check for issues
go vet ./...
# Lint code (if golangci-lint is installed)
golangci-lint run
Commit Message Convention
We follow the Conventional Commits specification:
feat:- New featuresfix:- Bug fixesdocs:- Documentation changesstyle:- Code style changesrefactor:- Code refactoringtest:- Test changeschore:- Maintenance tasks
Examples:
feat: add SSL certificate validation tool
fix: resolve timeout issue in ping tool
docs: update installation guide
test: add unit tests for DNS tool
Code Organization
Follow the clean architecture principles:
internal/
├── domain/ # Core business logic
│ ├── interfaces.go
│ ├── types.go
│ └── *_test.go
├── application/ # Use cases
│ ├── services/
│ └── handlers/
├── infrastructure/ # External dependencies
│ ├── network/
│ └── storage/
└── presentation/ # UI components
├── tui/
└── cli/
Testing Guidelines
Unit Tests
- Write tests for all public functions
- Aim for high test coverage (80%+)
- Use table-driven tests for multiple scenarios
- Mock external dependencies
Example:
func TestPingTool_Execute(t *testing.T) {
tests := []struct {
name string
params PingParameters
want PingResult
wantErr bool
}{
{
name: "successful ping",
params: PingParameters{
Host: "8.8.8.8",
Count: 4,
},
want: PingResult{
Host: "8.8.8.8",
// ... expected result
},
wantErr: false,
},
// ... more test cases
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
tool := &PingTool{}
got, err := tool.Execute(context.Background(), tt.params)
if (err != nil) != tt.wantErr {
t.Errorf("Execute() error = %v, wantErr %v", err, tt.wantErr)
return
}
if !reflect.DeepEqual(got, tt.want) {
t.Errorf("Execute() = %v, want %v", got, tt.want)
}
})
}
}
Integration Tests
- Test the complete workflow
- Use real network calls (with timeouts)
- Test error handling and edge cases
Performance Tests
- Benchmark critical functions
- Test with large datasets
- Monitor memory usage
func BenchmarkPingTool_Execute(b *testing.B) {
tool := &PingTool{}
params := PingParameters{
Host: "8.8.8.8",
Count: 4,
}
b.ResetTimer()
for i := 0; i < b.N; i++ {
_, err := tool.Execute(context.Background(), params)
if err != nil {
b.Fatal(err)
}
}
}
Documentation
Code Documentation
- Document all public functions and types
- Use Go doc comments
- Include examples for complex functions
// PingTool implements the DiagnosticTool interface for network ping operations.
// It provides ICMP ping functionality with configurable parameters.
type PingTool struct {
client NetworkClient
}
// Execute performs a ping operation to the specified host.
// It returns a PingResult containing packet information and statistics.
//
// Example:
// tool := &PingTool{client: networkClient}
// result, err := tool.Execute(ctx, PingParameters{
// Host: "google.com",
// Count: 4,
// })
func (p *PingTool) Execute(ctx context.Context, params Parameters) (Result, error) {
// Implementation...
}
User Documentation
- Update README.md for new features
- Add examples and use cases
- Update configuration documentation
- Add troubleshooting guides
Pull Request Process
Before Submitting
-
Ensure all tests pass
go test ./... -
Check code style
go fmt ./...
go vet ./... -
Update documentation
- Update README.md if needed
- Add/update doc comments
- Update configuration docs
-
Test your changes
- Test on different platforms
- Test with different configurations
- Test edge cases
Pull Request Template
When creating a pull request, include:
- Description: What changes were made and why
- Type: Feature, bug fix, documentation, etc.
- Testing: How the changes were tested
- Breaking Changes: Any breaking changes
- Screenshots: For UI changes
- Checklist: Ensure all items are completed
Review Process
- Automated Checks: CI/CD pipeline runs tests and checks
- Code Review: Maintainers review the code
- Testing: Changes are tested in different environments
- Approval: At least one maintainer must approve
- Merge: Changes are merged to main branch
Issue Reporting
Bug Reports
When reporting bugs, include:
- Description: Clear description of the issue
- Steps to Reproduce: Detailed steps
- Expected Behavior: What should happen
- Actual Behavior: What actually happens
- Environment: OS, Go version, etc.
- Logs: Relevant error messages or logs
Feature Requests
When requesting features, include:
- Description: Clear description of the feature
- Use Case: Why this feature is needed
- Proposed Solution: How you think it should work
- Alternatives: Other solutions considered
Community Guidelines
Code of Conduct
- Be respectful and inclusive
- Focus on constructive feedback
- Help others learn
- Follow the project's coding standards
Getting Help
- Check existing issues and discussions
- Ask questions in GitHub Discussions
- Join our Discord community
- Read the documentation
Release Process
Versioning
We follow Semantic Versioning:
- MAJOR: Breaking changes
- MINOR: New features (backward compatible)
- PATCH: Bug fixes (backward compatible)
Release Checklist
- All tests pass
- Documentation updated
- Changelog updated
- Version bumped
- Release notes prepared
- Tag created
- Release published
Recognition
Contributors are recognized in:
- CONTRIBUTORS.md file
- Release notes
- Project documentation
- GitHub contributors page
Thank you for contributing to NetTraceX! 🚀