Refactor misuse of Feature Flags and Learn to WRITE TESTS

**작성:** 25년 8월 27일
**착수:** 그래서 이거 언제 하지...?

**Branch:**
Create one if needed

**Related Files(3):**
- `com.example.accounts.config.FeatureFlags`
- `com.example.accounts.service.impl.AccountsServiceImpl `
- `src/main/resources/application.yml`

**Context:**
In `AccountsServiceImpl` `deleteAccount()`
```
if (FeatureFlags.DELETE_ACCOUNT_EXCEPTION_SIMULATION.equals(mobileNumber) &&
featureFlags.isFeatureEnabled(FeatureFlags.DELETE_ACCOUNT_EXCEPTION_SIMULATION)) {
throw new RuntimeException("DELETE_ACCOUNT_EXCEPTION_SIMULATION");
}
```
I am using the feature flag to simulate an exception for testing:
- Input-dependent (mobileNumber == "trigger")
- Environment-dependent (DEV profile only)
- **_This is not a classic production feature toggle. It’s more of a test hook or simulation mechanism._**

**Pros:**
- Works for safely testing edge cases in DEV
- Doesn’t affect PROD

🟥 **Cons:**
- **_It mixes test simulation with production code_**
- **_Not what most feature flags are intended for_**

------

✅ **Goal:**
- Learn and apply proper testing techniques to simulate edge cases without relying on production feature flags.
- Evaluate and apply feature flags correctly (e.g., real toggles for features, environment rollouts, etc.).

✅ **Reference:**
- Martin Fowler's article: https://martinfowler.com/articles/feature-toggles.html

-----

✅ **Resolution Summary:**
- Don’t use the feature flag for testing in production code.
- Move simulation logic into test-only helpers or mocks.
- Keep FeatureFlags strictly for real feature toggles.
- Update tests to cover the edge cases.

✅ **Resolution Plan:**

**Step 1: Analyze current usage**
- Review `deleteAccount()` and see how the feature flag is being used.
- Confirm that the “magic number” + DEV profile logic is really just for testing.
- Decide if this logic should stay in production code or be moved elsewhere.

**Step 2: Find a proper test mechanism**
- Goal: simulate exceptions or edge cases without using production feature flags.
- Options:
1) Dev-only helper or service
E.g., DevSimulationService.triggerDeleteAccountException(mobileNumber)
Only loaded in DEV profile
2) Unit/integration tests
Mock repository/service layers to throw exceptions when needed
No need to touch production code
3) Test configuration flags
Use @TestConfiguration in Spring for dev/test environment

**Step 3: Refactor code**
- Move the “test hook” logic out of AccountsServiceImpl.
- Keep FeatureFlags for real production toggles, not test-only simulations.

**Step 4: Update tests**
- Make sure my new dev-only simulation or mocks cover the scenarios you were testing with the “magic number.”
- Confirm behavior in both DEV and PROD profiles.

**Step 5: Review feature flag use cases**
Ensure the feature flag system is only used for production feature toggling:
- Gradual rollout
- Conditional behavior based on profile/user/group
- Quickly enable/disable features in PROD