Planning MVP test coverage

[Arlodotexe]

Basic tests pass now, we can start expanding to more specific test coverage.

What area needs test coverage the most for this project?

It depends on what will be utilized in the database migration. Which is... pretty much everything, if not most things. We can be more specific than that.

Let's take a look at the original migration ticket.

WindowsAppCommunity/uwpcommunity-backend#144

This has the original proposed new model, but it doesn't show what's in the old model.

Assessment of models supplied by prod backend API

I can just pull from the json on the website.

I can only get projects from the website. We need more than that, but we can at least start with project.

    {
        "id": 415,
        "appName": "PowerDisk - PC Cleaner",
        "description": "PowerDisk is a PC Cleaner that recovers disk space from any of your drives",
        "isPrivate": false,
        "downloadLink": "https://www.microsoft.com/store/apps/9PLPNC3D2N2T",
        "githubLink": null,
        "externalLink": null,
        "collaborators": [],
        "category": "Productivity",
        "createdAt": "2022-03-10T18:27:05.458Z",
        "updatedAt": "2022-03-10T18:27:05.458Z",
        "awaitingLaunchApproval": false,
        "needsManualReview": false,
        "images": [],
        "features": [],
        "tags": [],
        "heroImage": "https://store-images.s-microsoft.com/image/apps.16061.14313637298438354.d60e31f8-3557-48dd-8805-8b849d7a567a.9b53e9f5-f844-4d4a-be81-55dde3a74324?w=672&h=378&q=80&mode=letterbox&background=%23FFE4E4E4&format=jpg",
        "appIcon": "https://store-images.s-microsoft.com/image/apps.23052.14313637298438354.c0df153b-7223-4d32-83f7-ec91dff9e05a.009c0e0c-c8dc-432e-8861-0fd10c455d7c?mode=scale&q=90&h=300&w=200",
        "accentColor": null,
        "lookingForRoles": null
    }

Assessment of current prod database models

[crosspost] I'm doing a fresh evaluation of the database models in the current backend so we know exactly what we do and don't need here. MVP unit test coverage needs to proactively catch the bugs we're going to encounter during database migration.

I'm seeing these db models in the old codebase:

• Project
  • Has properties Id, appName, description, isPrivate, downloadLink, githubLink, externalLink, awaitingLaunchApproval, needsManualReview, lookingForRoles, heroImage, appIcon, accentColor, users list, tags list, userProjects list, category, and created/updated dates.
  • In the new codebase:
    • Project has an equivalent in IReadOnlyProject and IModifiableProject for interfaces, and ReadOnlyProject and ModifiableProject.
    • appName and description were kept as name and description
    • Links were consolidated into a links collection with labels and ids instead of separate fields for githubLink, downloadLink and externalLink.
    • awaitingLaunchApproval should be unused by any current projects, and won't be used later.
    • In the old codebase, needsManualReview represents the registration approval state in the windows app community discord server. In the new codebase, this is represented by the backlinking between a project's publisher to our community's publisher. If a project has true for this field, the project and publisher should be created and the publisher should be added as a parent publisher, but it should NOT be added to the Windows App Community publisher as a child publisher until staff has done the review process.
    • lookingForRoles is unused in the old codebase and doesn't exist in the new one, but could be built on top of the SDK.
    • heroImage and appIcon were superseded by an image collection where images may have Ids
    • accentColor was kept as-is
    • users list (connected through UserProject table here) was replaced with a 1:1 nomad-based equivalent for users collections (plus the new roles)
    • tags list was only used for things like Launch 2019/2020 and Uno Platform / Windows Community Toolkit. These will each need to be transformed to the new models.
      • Launch data will be handled in our extension to the SDK for the Appathon
      • Tags for Uno Platform and Community Toolkit will need to be transformed into project dependencies, directly referencing the registered projects for Uno Platform and Community Toolkit.
    • userProjects list connected Projects to Users
    • category was kept as-is
• ProjectFeature
  • Is a table that holds variants of a simple string property linked to a projectid
  • In the new codebase, this is included on the project object out of the box.
• ProjectImage
  • This is a simple string property that links a project to an image url.
  • This was superseded by "ImageCollection" in the new codebase.
• Role
  • Has an Id, a Name (Developer, Translator, Beta Tester, etc), and a createdat and udpatedat date.
  • In the new codebase:
    • This model is much more flexible, not restricted to any subset of roles.
• Tag
  • Has an Id, a name, an icon, and a list of projects.
  • only used for things like Launch 2019/2020 and Uno Platform / Windows Community Toolkit.
  • In the new codebase, this data will each need to be transformed to the new models.
    • Launch data will be handled in our extension to the SDK for the Appathon
    • Tags for Uno Platform and Community Toolkit will need to be transformed into project dependencies, directly referencing the registered projects for Uno Platform and Community Toolkit.
• User
  • User has an equivalent in IReadOnlyUser and IModifiableUser for interfaces, and ReadOnlyUser and ModifiableUser.
  • Has an Id, name, email, discordId, projects list, and created/updated dates.
  • The projects list is linked through the Project and UserProject model
  • In the new codebase:
    • name was kept as-is
    • email was superseded by the connections collection
    • discordId was superseded by the connections collection
    • projects/role list was superseded by the ModifiableProjectRoleCollection and ModifiableUserRoleCollection used by ModifiableUser and ModifiableProject, respectively.
• UserProject
  • Has an Id, an isOwner bool, a User and UserId, a Project and ProjectId, and a Role and RoleId.
  • This object maps a user to a project as a specific role.
  • In the new codebase:
    • isOwner would be:
      • Represented by a role instead
      • Verified by backlinking ipns between both user and project with a specific role
    • User/UserId is represented by placing the ipns in a user role collection on a project
    • Project/ProjectId is represented by placing the ipns in a project role collection on a user.
    • Role/RoleId is represented alongside the corresponding user/project on each link

Planning test coverage

Subsections for In the new codebase have been added and expanded on for each existing model listed above. This should give us everything we need to write tests to avoid surprises, complications and delays when we migrate the database to the new SDK.

We won't be migrating yet-- we're evaluating what MVP test coverage looks like, focusing on key SDK functionality.

There's still additional work to do to migrate all data over from the SDK, but will be sorted out before the migration phase to give us a chance to write tests. The above gives us a head start on the full list of requirements for migration.

[Arlodotexe]

Progress in c283b6f and 88d5a08

[Arlodotexe]

Further progress pushed as ce2be58 and d7cbd95.

The only remaining tests needed for MVP here are #24 and #22.

[Arlodotexe]

Tests for Links were enabled and passing in #37

[Arlodotexe]

• The only thing not tested is the connections handler.
  • This will be the first thing we manually test during integration with the discord bot.
• The only thing not accommodated by existing tooling is Tag data for past Launch events.
  • We'll build an extension to the SDK to handle this; likely a custom publisher added via connection.

The above in mind, we can close this ticket as completed.