What's the problem?

What are you trying to do? Is there a problem you're encountering or a wish you have that a new feature would address?

I am proposing and providing a draft for a possible test plan for automated testing

What's the design idea?

Figure out what is needed from the draft to include in the official documentation

Wordplay Test Plan - Automated Testing

Wordplay aims to make coding more fun and accessible–specifically around language. With the Beta launch out, the main concerns are around user data storage and security, where we want to make sure that users are able to have their work saved and stored in their accounts in Wordplay and not need to worry about losing all the progress they have made in their accounts. For testing, the current verification team has little experience in automated testing, therefore, all testing at first will be unit testing with a focus on the database files within VScode, src/db.

Testers will work on tests they select through the issues created for the tests on GitHub, and assign the issues to themselves. When the issue is created, Amy will triage the issue before testers begin writing the tests
Environment:
A testing account will be created within Wordplay for testers to create testing data the exact same way users would create data within their accounts. This allows for a testing environment that mimics real user conditions as closely as possible, and for testers to identify errors/issues that users may encounter.
The main devices to test on are laptops (Windows, Mac, Linux)/computers, and potentially mobile devices such as tablets and smartphones.

Vitest will be used for unit testing (No need to install, it is already included in the wordplay package)
- Unit testing: Asserts that an expected input will result in the expected output. Unit testing covers individual units of code (i.g. A function or method)
- Guide can be found on verification wiki page
Playwright will be used for end-to-end testing (No need to install, it is already included in the wordplay package)
- End-to-end testing (E2E): E2E tests simulate a user level experience, they capture and replay user actions–a recording of key user experience flows. Examples of what E2E tests cover include user stories like: “As a user, I want to be able to login in order to have and use my own account within Wordplay” or “As a user, I want to be able to create projects within wordplay and know that my projects will be there the next time I login”
- Guide can be found on verification wiki page
GitHub issues will be used for bug reporting and testing requests/reports, as well as other relevant problems within Wordplay that should be addressed.

Bugs or any issue within Wordplay shall be reported through writing issues in GitHub. There will be a guide as to what to include in the issue when you create a new issue.
Please notify the team manager via the Discord verification group chat on the issues submitted for easier management of issues
After submitting an issue, Amy will triage the issue and possibly add clarification question comments on the submitted issue, so please keep track of the issues you create and check consistently for her comments
Once issues have been triaged by Amy, the team manager will reach out to other teams as needed to find someone or a group to work on the issue

Risk of not enough coverage when it comes to writing tests
Afraid of feedback so no one submits requests/issues
- No one asks questions
Probability that if one function is changed after a test, it breaks another function (domino effect)

Export class ProjectsDexie extends Dexie
- Async getProject(id: string)
- Write unit test providing a string for the project id as input with an output checking that the project with this id is indeed found and selected
- Async deleteProject(id: string)
- Write unit test providing a string for the project id as input with an output checking that the project with this id is indeed found and deleted
- saveProjects(projects: Serialized Project[])
- Write unit test with the array of projects as the input with an output checking that all of the projects are saved in the database
- Async getAllProjects()
- Write unit test checking that all projects are selected and stored into the array of the liveQuery
Export default class ProjectsDatabase (Not sure if the code within this export default needs unit testing)
Async hydrate()
- Write unit test to check if the observable obtained from the local database syncs with wordplay