|
| 1 | +# Decision: Test Context vs Deployment Environment Naming |
| 2 | + |
| 3 | +## Status |
| 4 | + |
| 5 | +Accepted |
| 6 | + |
| 7 | +## Date |
| 8 | + |
| 9 | +2025-09-29 |
| 10 | + |
| 11 | +## Context |
| 12 | + |
| 13 | +The Torrust Tracker Deploy project has two distinct concepts that both could be called "environment": |
| 14 | + |
| 15 | +1. **Testing Context (Current `TestEnvironment`)**: A test harness managing temporary resources, SSH keys, services, and cleanup for end-to-end testing. |
| 16 | + |
| 17 | +2. **Multi-Environment Deployment (Planned Feature)**: Different deployment targets (dev, staging, production) with separate state, build artifacts, and persistent infrastructure. |
| 18 | + |
| 19 | +This naming collision could mislead contributors and create ambiguity in the codebase. |
| 20 | + |
| 21 | +## Decision |
| 22 | + |
| 23 | +### Final Choice |
| 24 | + |
| 25 | +- **`TestEnvironment` → `TestContext`**: Better represents a complete testing context with multiple resources |
| 26 | +- **Reserve `Environment` for multi-environment feature**: Aligns with industry standards (GitHub, AWS, Railway, Vercel) |
| 27 | + |
| 28 | +### Alternatives Discarded |
| 29 | + |
| 30 | +**For Testing Context:** |
| 31 | + |
| 32 | +- `TestFixture`: Too narrow, implies single resource rather than complete context |
| 33 | +- `TestHarness`: Less familiar to some developers |
| 34 | +- `TestSetup`: Generic, less descriptive |
| 35 | +- `TestSandbox`: Could suggest security focus rather than resource management |
| 36 | + |
| 37 | +**For Multi-Environment Feature:** |
| 38 | + |
| 39 | +- `Context`: Used by Docker/Kubernetes but less intuitive for deployment targets |
| 40 | +- `Workspace`: Used by Terraform differently, could conflict with IDE workspaces |
| 41 | +- `Target`: Less descriptive of full environment concept |
| 42 | +- `Stage`: Implies sequence, less flexible |
| 43 | +- `Stack`: Implies specific architecture |
| 44 | + |
| 45 | +## Why |
| 46 | + |
| 47 | +- **TestContext** accurately describes managing a complete testing context with multiple resources and services |
| 48 | +- **Environment** is the industry standard for deployment targets, making it immediately intuitive for users |
| 49 | +- Clear conceptual separation: `TestContext` for temporary test infrastructure, `Environment` for persistent deployment targets |
| 50 | + | `TestContext` ✅ | Conveys complete context management | Slightly longer | Testing frameworks, .NET | |
| 51 | + | `TestSandbox` | Implies isolation | Could suggest security focus | Containerization | |
| 52 | + | `TestWorkspace` | Suggests temporary work area | Could conflict with IDE workspaces | IDE terminology | |
| 53 | + |
| 54 | +### For Multi-Environment Feature (New Concept) |
| 55 | + |
| 56 | +| Name | Pros | Cons | Industry Usage | |
| 57 | +| ---------------- | ---------------------------- | ------------------------------------- | ---------------------------- | |
| 58 | +| `Environment` ✅ | Industry standard, intuitive | Could conflict with test environment | GitHub, AWS, Railway, Vercel | |
| 59 | +| `Context` | Used by Docker/Kubernetes | Less intuitive for deployment targets | Docker, Kubernetes | |
| 60 | +| `Workspace` | Clear isolation concept | Used by Terraform differently | Terraform | |
| 61 | +| `Target` | Clear deployment meaning | Less descriptive of full environment | Build systems | |
| 62 | +| `Stage` | Common in CI/CD | Implies sequence, less flexible | AWS, CI/CD pipelines | |
| 63 | +| `Stack` | Complete infrastructure set | Implies specific architecture | Pulumi, CloudFormation | |
| 64 | + |
| 65 | +## Decision |
| 66 | + |
| 67 | +We will adopt the following naming strategy: |
| 68 | + |
| 69 | +### 1. Rename `TestEnvironment` → `TestContext` |
| 70 | + |
| 71 | +**Rationale:** |
| 72 | + |
| 73 | +- `TestContext` better represents what the struct actually does: managing a complete testing context with multiple resources, configuration, and services |
| 74 | +- It's more accurate than "TestFixture" which implies a single resource |
| 75 | +- Common in testing frameworks and clearly distinguishes from deployment environments |
| 76 | +- Conveys the idea of a complete context that encompasses multiple concerns |
| 77 | + |
| 78 | +### 2. Use `Environment` for Multi-Environment Feature |
| 79 | + |
| 80 | +**Rationale:** |
| 81 | + |
| 82 | +- `Environment` is the industry standard term used by GitHub Actions, AWS, Railway, Vercel, and most DevOps tools |
| 83 | +- Users will immediately understand commands like `deploy --environment dev` or `deploy --environment staging` |
| 84 | +- Aligns with common DevOps terminology and user expectations |
| 85 | +- Most intuitive for the target use case |
| 86 | + |
| 87 | +### 3. Related Renames |
| 88 | + |
| 89 | +- `TestEnvironmentError` → `TestContextError` |
| 90 | +- `TestEnvironmentType` → `TestContextType` |
| 91 | +- Update field names: `environment_type` → `context_type` |
| 92 | +- Update documentation and comments throughout |
| 93 | + |
| 94 | +## Consequences |
| 95 | + |
| 96 | +### Positive |
| 97 | + |
| 98 | +- **Clear Conceptual Separation**: `TestContext` for temporary test infrastructure, `Environment` for persistent deployment targets |
| 99 | +- **Industry Alignment**: Users familiar with other DevOps tools will immediately understand the Environment concept |
| 100 | +- **Accurate Naming**: `TestContext` better describes the actual functionality |
| 101 | +- **Future-Proof**: Leaves `Environment` available for the more important multi-environment feature |
| 102 | + |
| 103 | +### Negative |
| 104 | + |
| 105 | +- **Refactoring Required**: Need to update existing code, tests, and documentation |
| 106 | +- **Temporary Disruption**: Developers working on branches will need to update their code |
| 107 | +- **Documentation Updates**: All references in docs and comments need updating |
| 108 | + |
| 109 | +### Neutral |
| 110 | + |
| 111 | +- **Learning Curve**: Minimal - `TestContext` is intuitive for developers familiar with testing frameworks |
| 112 | + |
| 113 | +## Implementation Plan |
| 114 | + |
| 115 | +1. Create this decision record |
| 116 | +2. Update `TestEnvironment` → `TestContext` in `src/e2e/environment.rs` |
| 117 | +3. Search for and update all references in other files |
| 118 | +4. Update documentation and module-level comments |
| 119 | +5. Update error types and messages |
| 120 | +6. Run tests to ensure no breakage |
| 121 | + |
| 122 | +## Examples After Implementation |
| 123 | + |
| 124 | +```rust |
| 125 | +// Test context usage |
| 126 | +let test_context = TestContext::initialized( |
| 127 | + false, |
| 128 | + "templates", |
| 129 | + &ssh_user, |
| 130 | + instance_name, |
| 131 | + ssh_private_key_path, |
| 132 | + ssh_public_key_path, |
| 133 | + TestContextType::Container, |
| 134 | +)?; |
| 135 | + |
| 136 | +// Future environment usage (planned) |
| 137 | +deploy --environment dev |
| 138 | +deploy --environment staging |
| 139 | +deploy --environment production |
| 140 | + |
| 141 | +struct Environment { |
| 142 | + name: String, |
| 143 | + build_dir: PathBuf, |
| 144 | + data_dir: PathBuf, |
| 145 | + config: EnvironmentConfig, |
| 146 | +} |
| 147 | +``` |
| 148 | + |
| 149 | +## Related Decisions |
| 150 | + |
| 151 | +This decision enables future work on: |
| 152 | + |
| 153 | +- Multi-environment deployment feature |
| 154 | +- Environment-specific configuration management |
| 155 | +- Independent state management per environment |
| 156 | + |
| 157 | +## References |
| 158 | + |
| 159 | +- Industry examples: GitHub Environments, AWS Environments, Docker Contexts, Terraform Workspaces |
| 160 | +- Testing terminology: xUnit TestFixture, .NET TestContext |
| 161 | +- Current codebase: `src/e2e/environment.rs` |
0 commit comments