You are called to build your own persistence infrastructure implementation by creating a new component that conforms to the <FeedStore> protocol.
Your custom persistence infrastructure implementation can be backed by any persistence stack you wish, i.e. CoreData, Realm, in memory, etc, as shown in the diagram below.
We advise you to invest some time and effort to produce a clean and well-presented solution to demonstrate your knowledge as it can be an ideal addition to your project portfolio!
- Fork the latest version of the challenge repo.
- Implement at least one
<FeedStore>implementation of your choice. - Use the
Tests/FeedStoreChallengeTests.swiftto validate your implementation. We recommend you to implement one test at a time. Follow the process: Make the test pass, commit, and move to the next one. In the end, all tests must pass. - If your implementation has failable operations (e.g., it might fail to load data from disk), uncomment and implement the failable test extensions at the bottom of the
Tests/FeedStoreChallengeTests.swifttest file. - When you’re done implementing your
<FeedStore>solution, create a Pull Request from your branch to the main challenge repo. Use the name of your implementation as the title for the Pull Request, for example, “CoreData implementation”. - Extra (optional): If your implementation persists the data across app launches (e.g., CoreData/Realm), you should add Integration Tests to check this behavior. In the lectures, we tested this behavior with Integration Tests in another target, but for this challenge, you can do it in the same test target.
- Aim to commit your changes every time you add/alter the behavior of your system or refactor your code.
- The system should always be in a green state, meaning that in each commit all tests should be passing.
- The project should build without warnings.
- The code should be carefully organized and easy to read (e.g. indentation must be consistent, etc.).
- Aim to create short methods respecting the Single Responsibility Principle.
- Aim to declare dependencies explicitly, instead of implicitly, leveraging dependency injection wherever necessary.
- Aim not to block the main thread. Strive to run operations in a background queue.
- Aim for descriptive commit messages that clarify the intent of your contribution which will help other developers understand your train of thought and purpose of changes.
- Make careful and proper use of access control, marking as
privateany implementation details that aren’t referenced from other external components. - Aim to write self-documenting code by providing context and detail when naming your components, avoiding explanations in comments.
Finally, add to this README file:
In order to not get forced to clear data base for each test, use magical linux specific black hole url: "/dev/null". everything you create and put inside this hole will not be retrievable.
