Skip to main content

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​

  1. Fork the repository

    # Fork the repository on GitHub, then clone your fork
    git clone https://github.com/your-username/nettracex-tui.git
    cd nettracex
  2. 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
  3. Build the project

    # Unix/Linux/macOS
    make build

    # Windows
    go build -o bin/nettracex.exe ./cmd/nettracex
  4. 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 gofmt to format your code
  • Use golint to check for style issues
  • Use go vet to 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 features
  • fix: - Bug fixes
  • docs: - Documentation changes
  • style: - Code style changes
  • refactor: - Code refactoring
  • test: - Test changes
  • chore: - 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​

  1. Ensure all tests pass

    go test ./...
  2. Check code style

    go fmt ./...
    go vet ./...
  3. Update documentation

    • Update README.md if needed
    • Add/update doc comments
    • Update configuration docs
  4. 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​

  1. Automated Checks: CI/CD pipeline runs tests and checks
  2. Code Review: Maintainers review the code
  3. Testing: Changes are tested in different environments
  4. Approval: At least one maintainer must approve
  5. 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! 🚀