feat(cc-digital-channel): add-uts-for-digital-channel

[akulakum]

COMPLETES #https://jira-eng-sjc12.cisco.com/jira/browse/CAI-7458

This pull request addresses

Adding comprehensive unit tests for the cc-digital-channels package to improve code coverage and test reliability.

by making the following changes

• Added unit tests for useDigitalChannelsInit and useDigitalChannelsData hooks covering initialization, error handling, and edge cases.
• Created dedicated DigitalChannelsComponent.test.tsx for presentational component tests (theme rendering, props validation).
• Added ErrorBoundary integration test for DigitalChannels component

Change Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Tooling change
• Internal code refactor

The following scenarios were tested

• The testing is done with the amplify link
  < ENUMERATE TESTS PERFORMED, WHETHER MANUAL OR AUTOMATED >

The GAI Coding Policy And Copyright Annotation Best Practices

• GAI was not used (or, no additional notation is required)
• Code was generated entirely by GAI
• GAI was used to create a draft that was subsequently customized or modified
• Coder created a draft manually that was non-substantively modified by GAI (e.g., refactoring was performed by GAI on manually written code)
• Tool used for AI assistance (GitHub Copilot / Other - specify)
  • Github Copilot
  • Other - Please Specify
• This PR is related to
  • Feature
  • Defect fix
  • Tech Debt
  • Automation

Checklist before merging

• I have not skipped any automated checks
• All existing and new tests passed
• I have updated the testing document
• I have tested the functionality with amplify link

---

Make sure to have followed the contributing guidelines before submitting.

[aws-amplify-us-east-2]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-611.d1b38q61t1z947.amplifyapp.com

[adhmenon]

LGTM. One question, only.

[adhmenon]

Do we know this is always going to be the default?

[akulakum]

Good catch! 'produs1' is not a default value - it's a mock test value we configure in the test setup. I've refactored to use a MOCK_DATA_CENTER constant to make this clearer. The test verifies that the component correctly receives whatever dataCenter value is configured in the store.

[rsarika]

Great work on adding comprehensive unit tests for the cc-digital-channels package! The tests are well-structured, follow proper MobX/React testing patterns, and cover important edge cases including error handling.

Highlights:

• Good use of act() with runInAction() for MobX state updates
• Proper mock strategy using jest.requireActual
• Nice refactor to use named constants for mock values
• Good coverage of error scenarios

Left a few minor suggestions as inline comments - these are non-blocking improvements for future consideration.

[rsarika]

Suggestion (non-blocking): Consider extracting the store state restoration logic into a nested describe block with afterEach for cleaner test isolation:

describe('when dataCenter is empty', () => {
  let originalDataCenter: string;
  
  beforeEach(() => {
    originalDataCenter = store.dataCenter;
    act(() => { runInAction(() => { store.dataCenter = ''; }); });
  });
  
  afterEach(() => {
    act(() => { runInAction(() => { store.dataCenter = originalDataCenter; }); });
  });
  
  it('should not render', async () => { /* ... */ });
});

This pattern makes test cleanup more explicit and less error-prone.

[akulakum]

Thanks for the suggestion! Refactored to use nested describe blocks with beforeEach/afterEach for dataCenter and currentTask tests. This makes the test cleanup more explicit and isolated.

[rsarika]

Suggestion (non-blocking): The consoleErrorSpy pattern is used multiple times. Consider extracting to a reusable helper or using beforeEach/afterEach:

let consoleErrorSpy: jest.SpyInstance;

beforeEach(() => {
  consoleErrorSpy = jest.spyOn(console, 'error').mockImplementation(() => {});
});

afterEach(() => {
  consoleErrorSpy.mockRestore();
});

[akulakum]

Good catch! Moved consoleErrorSpy to beforeEach/afterEach in the ErrorBoundary describe block. Also reset mockShouldThrow in afterEach for cleaner test isolation.

[rsarika]

Suggestion (non-blocking): Consider a more descriptive test name that captures the full scenario:

it('should handle token fetch error gracefully when logger is undefined')

This makes test failures easier to diagnose.

[akulakum]

Updated the test name to 'should handle token fetch error gracefully when logger is undefined' for better clarity on what scenario is being tested.

[rsarika]

Suggestion (non-blocking): There are several @ts-expect-error comments in these tests for the webex credentials API. For future maintainability, consider:

1. Creating a typed mock interface for the credentials API, or
2. Adding type definitions to the store's type declarations

This would improve IDE support and catch potential type mismatches early.

[akulakum]

This is a larger refactoring effort for future consideration - no changes made as it's non-blocking.