Test Coverage Assessment

Summary

This PR adds the Drive client foundation and parent command. While the OAuth scope change is covered by an updated test, the new internal/drive/ package (197 lines of logic) has no unit tests.

What's Tested

• OAuth scope update (internal/auth/auth_test.go): The test was properly updated to verify the new drive.DriveReadonlyScope is included. Good.

What's Missing Tests

1. internal/drive/files.go (125 lines) - No tests

This file contains business logic that should be tested:

• ParseFile() - Converts Drive API files to internal representation

  • Timestamp parsing (RFC3339 format)
  • Owner email extraction
  • Edge cases: nil owners, empty timestamps, malformed timestamps

• GetTypeName() - MIME type to human-readable name mapping

  • All switch cases (folder, document, spreadsheet, etc.)
  • Prefix matching fallback (image/, video/, audio/)
  • Unknown MIME type fallback

• IsGoogleWorkspaceFile() - Determines if a file needs export vs download

  • All workspace types return true
  • Non-workspace types return false

2. internal/drive/client.go (72 lines) - No tests

The Client struct and methods (ListFiles, GetFile) involve API calls, which are harder to test without mocks. However, I note that the interface (DriveClientInterface) is already defined, enabling mock-based testing. The existing codebase (see internal/gmail/client_test.go) uses similar patterns.

3. internal/cmd/drive/ - No tests

The parent command is minimal scaffolding, but output.go has a ClientFactory pattern ready for injection, suggesting the author intends to add tests later.

Recommendation

The pure functions in files.go (ParseFile, GetTypeName, IsGoogleWorkspaceFile) should have tests. They:

• Contain branching logic
• Will be relied upon by future subcommands
• Are easy to test (no external dependencies)

The client methods can wait until subcommands are added, as long as the interface is used for testability.

Verdict

Acceptable for merge with follow-up expected. This is foundation code and the architecture (interfaces, factory pattern) supports future testability. However, I'd recommend adding tests for files.go before building on top of it, either in this PR or a fast follow.

Added unit tests for internal/drive/files.go covering ParseFile, GetTypeName, and IsGoogleWorkspaceFile with edge cases as suggested in the TDD assessment.