test: unit test for display services

[Dhruwang]

What does this PR do?

Fixes 1566

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Chore (refactoring code, technical debt, workflow improvements)
• Enhancement (small improvements)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change adds a new database migration
• This change requires a documentation update

How should this be tested?

run test

Checklist

Required

• Filled out the "How to test" section in this PR
• Read How we Code at Formbricks
• Self-reviewed my own code
• Commented on my code in hard-to-understand bits
• Ran pnpm build
• Checked for warnings, there are none
• Removed all console.logs
• Merged the latest changes from main onto my branch with git pull origin main
• My changes don't cause any responsiveness issues
• First PR at Formbricks? Please sign the CLA! Without it we wont be able to merge it 🙏

Appreciated

• If a UI change was made: Added a screen recording or screenshots to this PR
• Updated the Formbricks Docs if changes were necessary

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
formbricks-cloud	⬜️ Ignored (Inspect)	Visit Preview		Jan 15, 2024 4:10pm
formbricks-com	⬜️ Ignored (Inspect)	Visit Preview		Jan 15, 2024 4:10pm

[github-actions]

Thank you for following the naming conventions for pull request titles! 🙏

[review-agent-prime]

packages/lib/display/service.ts

The status field is being set to null in multiple places in the code. This redundancy can be avoided by setting the default value of the status field to null in the database schema itself. This way, whenever a new record is created, if the status is not provided, it will automatically be set to null.

Create Issue
See the diff
Checkout the fix

    // In the Prisma schema file
    status String? @default(null)

git fetch origin && git checkout -b ReviewBot/Impro-gjgkhaw origin/ReviewBot/Impro-gjgkhaw

The error messages thrown in the catch blocks are generic. Providing more specific error messages can help in debugging and understanding the code better. For example, in the catch block of the getDisplay function, you can specify that the error occurred while fetching the display.

Create Issue
See the diff
Checkout the fix

    // In the catch block of the getDisplay function
    if (error instanceof Prisma.PrismaClientKnownRequestError) {
      throw new DatabaseError(`Error fetching display: ${error.message}`);
    }

git fetch origin && git checkout -b ReviewBot/Impro-43v0lrk origin/ReviewBot/Impro-43v0lrk

In the createDisplay function, there are two database calls being made when the userId is provided - one to fetch the person and another to create the person if it doesn't exist. This can be optimized by using the upsert operation provided by Prisma. The upsert operation will create the person if it doesn't exist, or update it if it does, in a single database call.

Create Issue
See the diff
Checkout the fix

    // In the createDisplay function
    if (userId) {
      person = await prisma.person.upsert({
        where: { userId: userId },
        update: {},
        create: { userId: userId, environmentId: environmentId }
      });
    }

git fetch origin && git checkout -b ReviewBot/Impro-dxpszdr origin/ReviewBot/Impro-dxpszdr

[mattinannt]

@Dhruwang thanks a lot for the tests! 💪 They look great, but your updates to the display service aren't aligned with the goals of the services:

[mattinannt]

same as above

[mattinannt]

@Dhruwang thank you for the changes :-) you missed two but I changed them now :-)