Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat/be/maintenance window module tests #1127

Merged
merged 2 commits into from
Nov 11, 2024

Conversation

ajhollid
Copy link
Collaborator

@ajhollid ajhollid commented Nov 8, 2024

This PR adds tetsts for the MaintenanceWindow module

  • Add missing await to editMaintenanceWindow
  • Add tests for maintenance window module

Copy link

@llamapreview llamapreview bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto Pull Request Review from LlamaPReview

1. Overview

1.1 PR Summary

  • Business value and requirements alignment: The PR aims to add tests for the MaintenanceWindow module and fix a missing await in the editMaintenanceWindowById function. This enhances test coverage and ensures the reliability of the MaintenanceWindow module, which is crucial for system maintenance planning.
  • Key components modified: The maintenanceWindowModule.js and a new test file maintenanceWindowModule.test.js.
  • Impact assessment: Minimal cross-component impact; the changes are isolated to the MaintenanceWindow module and its tests.
  • System dependencies and integration impacts: No impact on existing integration points.

1.2 Architecture Changes

  • System design modifications: None. The changes are localized to the MaintenanceWindow module.
  • Component interactions: None. The existing interactions with the module remain unchanged.
  • Integration points: None. The integration points are not affected by these changes.

2. Detailed Technical Analysis

2.1 Code Logic Deep-Dive

Core Logic Changes

File Path: Server/db/mongo/modules/maintenanceWindowModule.js
Function: editMaintenanceWindowById
  • Submitted PR Code:
    const editMaintenanceWindowById = async (maintenanceWindowId, maintenanceWindowData) => {
      try {
    -    const editedMaintenanceWindow = MaintenanceWindow.findByIdAndUpdate(
    +    const editedMaintenanceWindow = await MaintenanceWindow.findByIdAndUpdate(
          maintenanceWindowId,
          maintenanceWindowData,
          { new: true }
        );
        return editedMaintenanceWindow;
      } catch (error) {
        error.service = SERVICE_NAME;
        error.method = "editMaintenanceWindowById";
        throw error;
      }
    };
  • Analysis:
    • Current logic and potential issues: The previous code was missing an await keyword, which could lead to asynchronous issues.
    • Edge cases and error handling: The error handling is well-implemented, capturing and throwing the error with additional context.
    • Cross-component impact: None.
    • Business logic considerations: None.
  • LlamaPReview Suggested Improvements:
    const editMaintenanceWindowById = async (maintenanceWindowId, maintenanceWindowData) => {
      try {
        const editedMaintenanceWindow = await MaintenanceWindow.findByIdAndUpdate(
          maintenanceWindowId,
          maintenanceWindowData,
          { new: true }
        );
        return editedMaintenanceWindow;
      } catch (error) {
        console.error(`Error in editMaintenanceWindowById: ${error.message}`);
        error.service = SERVICE_NAME;
        error.method = "editMaintenanceWindowById";
        throw error;
      }
    };
  • Improvement rationale:
    • Technical benefits: Ensures that the asynchronous operation completes before proceeding.
    • Business value: Enhances the reliability of maintenance window edits.
    • Risk assessment: Low risk; the change is a straightforward fix.

2.2 Implementation Quality

  • Code Structure:

    • Organization and modularity: The code is well-organized and modular.
    • Design pattern adherence: Follows standard asynchronous patterns.
    • Reusability aspects: The functions are reusable within the module.
    • Maintainability factors: The code is easy to read and understand.
  • Error Handling:

    • Exception scenarios coverage: Comprehensive error handling with contextual information.
    • Recovery mechanisms: Errors are thrown with additional context, aiding in debugging.
    • Logging and monitoring: No logging implemented; consider adding logging for better monitoring.
    • User experience impact: Minimal; errors are handled internally.
  • Performance Considerations:

    • Resource utilization: Efficient use of resources.
    • Scalability aspects: The changes do not impact scalability.
    • Bottleneck analysis: No bottlenecks identified.
    • Optimization opportunities: None identified.

3. Critical Findings

3.1 Potential Issues

  • 🔴 Critical Issues

    • Issue description: No critical issues identified.
    • Impact: None.
    • Recommendation: None required.
  • 🟡 Warnings

    • Warning description: Add logging for better monitoring and debugging.
    • Potential risks:
      • Performance implications: None.
      • Maintenance overhead: Slightly increased due to additional logging.
      • Future scalability: None.
    • Suggested improvements:
      • Implementation approach: Add logging statements in the catch blocks.
      • Migration strategy: Simple addition of logging statements.
      • Testing considerations: Ensure logs are generated as expected.

3.2 Code Quality Concerns

  • Maintainability aspects: The code is well-organized and modular, but lacks inline comments for better readability.
  • Readability issues: None.
  • Performance bottlenecks: None identified.

4. Security Assessment

4.1 Security Considerations

  • Authentication/Authorization impacts: None.
  • Data handling concerns: None.
  • Input validation: Inputs are validated through MongoDB schema.
  • Security best practices: Compliant with existing security standards.

4.2 Vulnerability Analysis

  • Potential security risks: None identified.
  • Mitigation strategies: None required.
  • Security testing requirements: None identified.

5. Testing Strategy

5.1 Test Coverage

  • Unit test requirements: Comprehensive unit tests for all functions.
  • Integration test scenarios: Not applicable for this PR.
  • Edge case validation: All edge cases are validated in the tests.

5.2 Test Recommendations

Suggested Test Cases

// Example test case for logging
describe("editMaintenanceWindowById with logging", () => {
  it("should log an error if the update fails", async () => {
    const err = new Error("test error");
    maintenanceWindowFindByIdAndUpdateStub.rejects(err);
    const consoleErrorSpy = sinon.spy(console, "error");

    try {
      await editMaintenanceWindowById(mockMaintenanceWindow.id, mockMaintenanceWindow);
    } catch (error) {
      expect(consoleErrorSpy.calledWith(`Error in editMaintenanceWindowById: ${err.message}`)).to.be.true;
    }

    consoleErrorSpy.restore();
  });
});
  • Coverage improvements: Ensure logs are generated as expected.
  • Performance testing needs: Not applicable for this PR.

6. Documentation & Maintenance

  • Documentation updates needed: Add inline comments to describe the function's purpose.
  • Long-term maintenance considerations: Easy to maintain due to modular and well-organized code.
  • Technical debt and monitoring requirements: Low technical debt; consider adding logging for better monitoring.

7. Deployment & Operations

  • Deployment impact and strategy: Minimal. The changes are isolated to the MaintenanceWindow module.
  • Key operational considerations: None.

8. Summary & Recommendations

8.1 Key Action Items

  1. Critical changes required: None identified.
  2. Important improvements suggested:
    • Add logging for better monitoring and debugging.
  3. Best practices to implement:
    • Add inline comments to describe the purpose of each function.
  4. Cross-cutting concerns to address:
    • Ensure proper logging and comments for future maintainability.

8.2 Future Considerations

  • Technical evolution path: Continue to enhance test coverage and reliability of the system.
  • Business capability evolution: Ensure the MaintenanceWindow module remains robust and reliable.
  • System integration impacts: Minimal impact on existing integration points.

By addressing the identified improvements, the PR will not only meet its current objectives but also enhance the overall quality and maintainability of the MaintenanceWindow module.

Copy link

coderabbitai bot commented Nov 8, 2024

Walkthrough

The changes in this pull request involve modifications to the editMaintenanceWindowById function in the maintenanceWindowModule.js file, specifically adding the await keyword to the findByIdAndUpdate method call. This change ensures that the promise is resolved before continuing, making the function's asynchronous behavior more explicit. Additionally, a new test file has been introduced, maintenanceWindowModule.test.js, which includes a suite of unit tests for various functionalities of the MaintenanceWindow module, utilizing stubs to simulate database interactions.

Changes

File Path Change Summary
Server/db/mongo/modules/maintenanceWindowModule.js Modified the editMaintenanceWindowById function to include await for the findByIdAndUpdate method, enhancing control flow and ensuring proper asynchronous behavior.
Server/tests/db/maintenanceWindowModule.test.js Introduced a new test suite for the MaintenanceWindow module, covering creation, retrieval, editing, and deletion functionalities, including error handling scenarios.

Possibly related PRs

  • Feat/be/maintenance-window-controller-tests, #924 #935: This PR introduces tests for the maintenanceWindowController, which includes the editMaintenanceWindow function that was modified in the main PR. The changes in both PRs are directly related to the same function, ensuring that the behavior of editMaintenanceWindow is thoroughly tested.
  • Feat/be/monitor module refactor #1114: This PR refactors the monitorModule, which includes the getMonitorChecks function that may interact with maintenance windows. While the main PR focuses on the editMaintenanceWindow function, the overall improvements in the monitor module could relate to how maintenance windows are managed or displayed in the application.

Suggested reviewers

  • marcelluscaio
  • jennifer-gan

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

‼️ IMPORTANT
Auto-reply has been disabled for this repository in the CodeRabbit settings. The CodeRabbit bot will not respond to your replies unless it is explicitly tagged.

  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🧹 Outside diff range and nitpick comments (7)
Server/db/mongo/modules/maintenanceWindowModule.js (3)

Line range hint 206-210: Yo dawg, that await addition is straight fire! 🔥

The addition of the await keyword fixes a critical issue that could have caused inconsistent behavior and race conditions. This change ensures we properly wait for the database operation to complete.

Consider adding parameter validation to prevent potential issues:

 const editMaintenanceWindowById = async (maintenanceWindowId, maintenanceWindowData) => {
   try {
+    if (!maintenanceWindowId) {
+      throw new Error('maintenanceWindowId is required');
+    }
+    if (!maintenanceWindowData || typeof maintenanceWindowData !== 'object') {
+      throw new Error('maintenanceWindowData must be a valid object');
+    }
     const editedMaintenanceWindow = await MaintenanceWindow.findByIdAndUpdate(

Line range hint 205-217: Mom's spaghetti says we need some documentation! 📝

Unlike other functions in this module, editMaintenanceWindowById is missing JSDoc documentation. Let's keep it consistent with the rest of the codebase.

Add this documentation above the function:

/**
 * Asynchronously updates a MaintenanceWindow document by its ID.
 * @async
 * @function editMaintenanceWindowById
 * @param {mongoose.Schema.Types.ObjectId} maintenanceWindowId - The ID of the MaintenanceWindow document to update.
 * @param {Object} maintenanceWindowData - The updated data for the MaintenanceWindow document.
 * @returns {Promise<MaintenanceWindow>} The updated MaintenanceWindow document.
 * @throws {Error} If there is an error updating the document.
 * @example
 * editMaintenanceWindowById('maintenanceWindowId', { active: false })
 *   .then(maintenanceWindow => console.log(maintenanceWindow))
 *   .catch(error => console.error(error));
 */

Line range hint 1-217: Knees weak, arms heavy, but this module's structure is steady! 💪

The module demonstrates solid practices:

  • Consistent error handling across all functions
  • Clean MongoDB operations with proper async/await usage
  • Well-organized exports
  • Comprehensive documentation (except for the noted function)

Consider adding input sanitization middleware or a validation layer to ensure data consistency before it reaches these database operations.

Server/tests/db/maintenanceWindowModule.test.js (4)

15-21: Yo dawg, let's beef up that mock data!

The mock maintenance window could use more realistic test data. Consider adding:

  • teamId (used in tests but missing from mock)
  • userId (used in tests but missing from mock)
  • name (used in sorting tests)
 const mockMaintenanceWindow = {
+    id: "mw_123",
     monitorId: "123",
+    teamId: "team_123",
+    userId: "user_123",
+    name: "Scheduled Maintenance",
     active: true,
     oneTime: true,
     start: 1,
     end: 20000,
 };

178-195: There's vomit on his sweater already - we're missing some test cases!

Consider adding these test cases:

  • Empty result set
  • Multiple maintenance windows
  • Invalid monitorId format
+it("should return empty array when no maintenance windows exist", async () => {
+    maintenanceWindowFindStub.resolves([]);
+    const result = await getMaintenanceWindowsByMonitorId("non_existent_monitor");
+    expect(result).to.deep.equal([]);
+});

+it("should handle multiple maintenance windows", async () => {
+    const multipleWindows = [mockMaintenanceWindow, {...mockMaintenanceWindow, id: "mw_456"}];
+    maintenanceWindowFindStub.resolves(multipleWindows);
+    const result = await getMaintenanceWindowsByMonitorId(mockMaintenanceWindow.monitorId);
+    expect(result).to.have.length(2);
+});

65-73: Lose yourself in better error handling!

The error handling tests should be more specific about different types of errors:

  • Database connection errors
  • Validation errors
  • Permission errors

Example improvement:

-it("should handle an error", async () => {
+it("should handle database connection error", async () => {
-    const err = new Error("test error");
+    const err = new Error("MongoNetworkError: connection failed");
     maintenanceWindowSaveStub.rejects(err);
     try {
         await createMaintenanceWindow(mockMaintenanceWindow);
+        expect.fail("Should have thrown an error");
     } catch (error) {
         expect(error).to.deep.equal(err);
+        expect(error.message).to.include("MongoNetworkError");
     }
 });

+it("should handle validation error", async () => {
+    const err = new Error("ValidationError: start date must be before end date");
+    maintenanceWindowSaveStub.rejects(err);
+    try {
+        await createMaintenanceWindow({ ...mockMaintenanceWindow, start: 30000, end: 1 });
+        expect.fail("Should have thrown an error");
+    } catch (error) {
+        expect(error.message).to.include("ValidationError");
+    }
+});

Also applies to: 81-89, 168-176, 186-194, 202-210, 221-229, 238-246, 257-265


14-31: Clean up that spaghetti code with test utilities!

Consider extracting common test utilities:

// testUtils.js
export const createMockMaintenanceWindow = (overrides = {}) => ({
    id: "mw_123",
    monitorId: "123",
    teamId: "team_123",
    userId: "user_123",
    name: "Scheduled Maintenance",
    active: true,
    oneTime: true,
    start: 1,
    end: 20000,
    ...overrides
});

export const setupStubs = () => ({
    save: sinon.stub(MaintenanceWindow.prototype, "save"),
    findById: sinon.stub(MaintenanceWindow, "findById"),
    // ... other stubs
});
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between ddb40bb and 247c034.

📒 Files selected for processing (2)
  • Server/db/mongo/modules/maintenanceWindowModule.js (1 hunks)
  • Server/tests/db/maintenanceWindowModule.test.js (1 hunks)

Comment on lines +108 to +118
it("should return a list of maintenance windows and count", async () => {
maintenanceWindowCountDocumentsStub.resolves(1);
const result = await getMaintenanceWindowsByTeamId(
mockMaintenanceWindow.teamId,
query
);
expect(result).to.deep.equal({
maintenanceWindows: mockMaintenanceWindows,
maintenanceWindowCount: 1,
});
});
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Knees weak, arms heavy - we need to verify those query params!

The test should explicitly verify the query parameters passed to the stubs:

 it("should return a list of maintenance windows and count", async () => {
     maintenanceWindowCountDocumentsStub.resolves(1);
     const result = await getMaintenanceWindowsByTeamId(
         mockMaintenanceWindow.teamId,
         query
     );
+    expect(maintenanceWindowFindStub.calledWith({ teamId: mockMaintenanceWindow.teamId, active: true })).to.be.true;
+    expect(maintenanceWindowCountDocumentsStub.calledWith({ teamId: mockMaintenanceWindow.teamId, active: true })).to.be.true;
     expect(result).to.deep.equal({
         maintenanceWindows: mockMaintenanceWindows,
         maintenanceWindowCount: 1,
     });
 });

Committable suggestion skipped: line range outside the PR's diff.

Comment on lines +58 to +74
describe("createMaintenanceWindow", () => {
it("should save a new maintenance window", async () => {
maintenanceWindowSaveStub.resolves(mockMaintenanceWindow);
const result = await createMaintenanceWindow(mockMaintenanceWindow);
expect(result).to.deep.equal(mockMaintenanceWindow);
});

it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowSaveStub.rejects(err);
try {
await createMaintenanceWindow(mockMaintenanceWindow);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
});
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Mom's spaghetti says we need more assertions!

The test suite should verify that the stub was called with the correct arguments:

 it("should save a new maintenance window", async () => {
     maintenanceWindowSaveStub.resolves(mockMaintenanceWindow);
     const result = await createMaintenanceWindow(mockMaintenanceWindow);
     expect(result).to.deep.equal(mockMaintenanceWindow);
+    expect(maintenanceWindowSaveStub.calledOnce).to.be.true;
+    expect(maintenanceWindowSaveStub.calledWith()).to.be.true;
 });

Committable suggestion skipped: line range outside the PR's diff.

Comment on lines +248 to +266
describe("editMaintenanceWindowById", () => {
it("should return the updated maintenance window", async () => {
maintenanceWindowFindByIdAndUpdateStub.resolves(mockMaintenanceWindow);
const result = await editMaintenanceWindowById(
mockMaintenanceWindow.id,
mockMaintenanceWindow
);
expect(result).to.deep.equal(mockMaintenanceWindow);
});
it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowFindByIdAndUpdateStub.rejects(err);
try {
await editMaintenanceWindowById(mockMaintenanceWindow.id, mockMaintenanceWindow);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
});
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Palms are sweaty - we need to validate those update options!

The test should verify:

  • The update options (e.g., { new: true })
  • Partial updates
  • Non-existent ID handling
 it("should return the updated maintenance window", async () => {
     maintenanceWindowFindByIdAndUpdateStub.resolves(mockMaintenanceWindow);
     const result = await editMaintenanceWindowById(
         mockMaintenanceWindow.id,
         mockMaintenanceWindow
     );
+    expect(maintenanceWindowFindByIdAndUpdateStub.calledWith(
+        mockMaintenanceWindow.id,
+        mockMaintenanceWindow,
+        { new: true }
+    )).to.be.true;
     expect(result).to.deep.equal(mockMaintenanceWindow);
 });

+it("should handle non-existent maintenance window", async () => {
+    maintenanceWindowFindByIdAndUpdateStub.resolves(null);
+    const result = await editMaintenanceWindowById("non_existent_id", mockMaintenanceWindow);
+    expect(result).to.be.null;
+});

+it("should handle partial updates", async () => {
+    const partialUpdate = { active: false };
+    const updatedWindow = { ...mockMaintenanceWindow, ...partialUpdate };
+    maintenanceWindowFindByIdAndUpdateStub.resolves(updatedWindow);
+    const result = await editMaintenanceWindowById(mockMaintenanceWindow.id, partialUpdate);
+    expect(result).to.deep.equal(updatedWindow);
+});
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
describe("editMaintenanceWindowById", () => {
it("should return the updated maintenance window", async () => {
maintenanceWindowFindByIdAndUpdateStub.resolves(mockMaintenanceWindow);
const result = await editMaintenanceWindowById(
mockMaintenanceWindow.id,
mockMaintenanceWindow
);
expect(result).to.deep.equal(mockMaintenanceWindow);
});
it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowFindByIdAndUpdateStub.rejects(err);
try {
await editMaintenanceWindowById(mockMaintenanceWindow.id, mockMaintenanceWindow);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
});
describe("editMaintenanceWindowById", () => {
it("should return the updated maintenance window", async () => {
maintenanceWindowFindByIdAndUpdateStub.resolves(mockMaintenanceWindow);
const result = await editMaintenanceWindowById(
mockMaintenanceWindow.id,
mockMaintenanceWindow
);
expect(maintenanceWindowFindByIdAndUpdateStub.calledWith(
mockMaintenanceWindow.id,
mockMaintenanceWindow,
{ new: true }
)).to.be.true;
expect(result).to.deep.equal(mockMaintenanceWindow);
});
it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowFindByIdAndUpdateStub.rejects(err);
try {
await editMaintenanceWindowById(mockMaintenanceWindow.id, mockMaintenanceWindow);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
it("should handle non-existent maintenance window", async () => {
maintenanceWindowFindByIdAndUpdateStub.resolves(null);
const result = await editMaintenanceWindowById("non_existent_id", mockMaintenanceWindow);
expect(result).to.be.null;
});
it("should handle partial updates", async () => {
const partialUpdate = { active: false };
const updatedWindow = { ...mockMaintenanceWindow, ...partialUpdate };
maintenanceWindowFindByIdAndUpdateStub.resolves(updatedWindow);
const result = await editMaintenanceWindowById(mockMaintenanceWindow.id, partialUpdate);
expect(result).to.deep.equal(updatedWindow);
});
});

Comment on lines +1 to +267
it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowCountDocumentsStub.rejects(err);
try {
await getMaintenanceWindowsByTeamId(mockMaintenanceWindow.teamId, query);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
});
describe("getMaintenanceWindowsByMonitorId", () => {
it("should return a list of maintenance windows", async () => {
maintenanceWindowFindStub.resolves(mockMaintenanceWindows);
const result = await getMaintenanceWindowsByMonitorId(
mockMaintenanceWindow.monitorId
);
expect(result).to.deep.equal(mockMaintenanceWindows);
});
it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowFindStub.rejects(err);
try {
await getMaintenanceWindowsByMonitorId(mockMaintenanceWindow.monitorId);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
});
describe("deleteMaintenanceWindowById", () => {
it("should delete a maintenance window", async () => {
maintenanceWindowFindByIdAndDeleteStub.resolves(mockMaintenanceWindow);
const result = await deleteMaintenanceWindowById(mockMaintenanceWindow.id);
expect(result).to.deep.equal(mockMaintenanceWindow);
});
it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowFindByIdAndDeleteStub.rejects(err);
try {
await deleteMaintenanceWindowById(mockMaintenanceWindow.id);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
});

describe("deleteMaintenanceWindowByMonitorId", () => {
it("should return the number of documents deleted", async () => {
maintenanceWindowDeleteManyStub.resolves({ deletedCount: 1 });
const result = await deleteMaintenanceWindowByMonitorId(
mockMaintenanceWindow.monitorId
);
expect(result).to.deep.equal({ deletedCount: 1 });
});
it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowDeleteManyStub.rejects(err);
try {
await deleteMaintenanceWindowByMonitorId(mockMaintenanceWindow.monitorId);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
});

describe("deleteMaintenanceWindowByUserId", () => {
it("should return the number of documents deleted", async () => {
maintenanceWindowDeleteManyStub.resolves({ deletedCount: 1 });
const result = await deleteMaintenanceWindowByUserId(mockMaintenanceWindow.userId);
expect(result).to.deep.equal({ deletedCount: 1 });
});
it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowDeleteManyStub.rejects(err);
try {
await deleteMaintenanceWindowByUserId(mockMaintenanceWindow.userId);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
});
describe("editMaintenanceWindowById", () => {
it("should return the updated maintenance window", async () => {
maintenanceWindowFindByIdAndUpdateStub.resolves(mockMaintenanceWindow);
const result = await editMaintenanceWindowById(
mockMaintenanceWindow.id,
mockMaintenanceWindow
);
expect(result).to.deep.equal(mockMaintenanceWindow);
});
it("should handle an error", async () => {
const err = new Error("test error");
maintenanceWindowFindByIdAndUpdateStub.rejects(err);
try {
await editMaintenanceWindowById(mockMaintenanceWindow.id, mockMaintenanceWindow);
} catch (error) {
expect(error).to.deep.equal(err);
}
});
});
});
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Yo, these tests are fire, but they could use some coverage swagger! 🔥

The test suite is solid with good error handling and edge cases, but there's no test coverage configuration in sight. Consider adding:

  1. Create a jest.config.js in the root directory with coverage settings:
module.exports = {
  collectCoverage: true,
  coverageReporters: ['text', 'lcov'],
  collectCoverageFrom: [
    'Server/db/mongo/modules/*.js'
  ],
  coverageThreshold: {
    global: {
      branches: 80,
      functions: 80,
      lines: 80,
      statements: 80
    }
  }
}
  1. Add a coverage script to package.json:
{
  "scripts": {
    "test:coverage": "jest --coverage"
  }
}
🔗 Analysis chain

He's nervous, but on the surface the tests look calm and ready!

Consider adding test coverage configuration:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if Jest configuration exists
if [ -f "jest.config.js" ]; then
    echo "Jest config found. Add coverage configuration:"
    cat << 'EOF'
module.exports = {
  collectCoverage: true,
  coverageReporters: ['text', 'lcov'],
  collectCoverageFrom: [
    'Server/db/mongo/modules/maintenanceWindowModule.js'
  ],
  coverageThreshold: {
    global: {
      branches: 80,
      functions: 80,
      lines: 80,
      statements: 80
    }
  }
}
EOF
else
    echo "No Jest config found. Consider adding one for coverage reporting."
fi

Length of output: 168


Script:

#!/bin/bash
# Let's check if there are any test configuration files in the repository
fd -e config.js -e config.json -e config.ts

# Also check package.json for test configuration
if [ -f "package.json" ]; then
    echo "=== Package.json Jest Config ==="
    cat package.json | jq '.jest'
fi

# Check if there's any coverage reporting in existing test commands
if [ -f "package.json" ]; then
    echo "=== Test Scripts ==="
    cat package.json | jq '.scripts | select(. != null) | with_entries(select(.key | contains("test")))'
fi

Length of output: 119


Script:

#!/bin/bash
# Let's check the test files for any existing coverage configuration
rg -l "coverage|collectCoverage" Server/tests

# Check if there's a .nycrc or similar coverage config
fd -g '.nycrc*'
fd -g '.coverage*'

# Check if there are any test runner configurations in the Server directory
fd -g '*test*config*' Server/

Length of output: 534

@ajhollid ajhollid merged commit 64c5c62 into develop Nov 11, 2024
3 checks passed
@ajhollid ajhollid deleted the feat/be/maintenance-window-module-tests branch November 11, 2024 23:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants