open-feature / open-feature/swift-sdk
Add InMemory Provider and Basic E2E Tests
- Dominant language
- Swift
- Stars
- 31
- Forks
- 14
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 2
Description
**Specification References:**
- [In-memory provider](https://openfeature.dev/specification/appendix-a#in-memory-provider)
- [E2E testing](https://openfeature.dev/specification/appendix-a#sdk-end-to-end-testing)
- [Gherkin suite](https://openfeature.dev/specification/appendix-b)
Steps:
- Implement in-memory provider
- Add [gherkin suite](https://github.com/open-feature/spec/tree/main/specification/assets/gherkin) as submodule and implement `evaluation.feature` with cucumber (either [CucumberSwift](https://github.com/cucumberswift/CucumberSwift) or the older [cumumberish](https://cucumber.io/docs/installation/ios)), with flags backed by the in-memory provider
- See [Java](https://github.com/open-feature/java-sdk/tree/main/src/test/java/dev/openfeature/sdk/e2e), [JS](https://github.com/open-feature/js-sdk/tree/main/packages/server/e2e), [Go](https://github.com/open-feature/go-sdk/tree/main/e2e), and other SDKs for examples
The In-memory provider and `evaluation.feature` e2e tests are important for validating the basic end-to-end behavior of the SDK, since it involves no mocks or stubs, and does a real evaluation.
Contributor guide
Research direction
Start by reading the linked in-memory provider and end-to-end testing specifications, then compare the referenced Java, JS, and Go SDK implementations. Add the Gherkin suite as a submodule and implement evaluation.feature with CucumberSwift or cumumberish, backed by the in-memory provider. Done means the provider works and the evaluation.feature end-to-end tests pass without mocks or stubs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- mobile-dev, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100