Describe the feature or problem you'd like to solve

The current test suite usesmigueleliasweb/go-github-mock for mocking GitHub REST API responses in unit tests. While this library has served us well, there are several reasons to consider replacing it withstretchr/testify/mock:

1. Dependency Consolidation: We already usestretchr/testify for assertions (assert andrequire). Usingtestify/mock would consolidate our testing dependencies.

2. Interface-based Mocking:testify/mock encourages interface-based mocking, which leads to better separation of concerns and more flexible test design.

3. Maintenance & Activity:stretchr/testify is one of the most widely used Go testing libraries with active maintenance.

4. Type Safety: Interface-based mocking provides compile-time type checking, whereas HTTP-level mocking relies on runtime matching.

5. Reduced Dependencies: One less external dependency to maintain

Proposed solution

Replace HTTP-level mocking with interface-based mocking usingtestify/mock:

Phase 1: Create Mock Interfaces

1. Define interfaces for GitHub client operations (if not already present)
2. Create mock implementations usingtestify/mock
3. Update the codebase to depend on interfaces rather than concrete clients

Phase 2: Migrate Tests Incrementally

1. Start with a single test file to establish patterns
2. Create helper functions for common mock setups
3. Migrate remaining test files one at a time
4. Removego-github-mock dependency when complete

Example Migration

Before (HTTP-level mocking):

mockedClient:=mock.NewMockedHTTPClient(mock.WithRequestMatch(mock.GetReposIssuesByOwnerByRepoByIssueNumber,mockIssue,    ),)client:=github.NewClient(mockedClient)

After (Interface-based mocking):

mockClient:=new(MockGitHubClient)mockClient.On("GetIssue",ctx,"owner","repo",42).Return(mockIssue,nil)

Related

• stretchr/testify documentation
• Current testing guidelines:docs/testing.md