Used Claude Code to increase test coverage

.github/workflows/tests.yml

@@ -0,0 +1,64 @@
+name: Tests
+
+on:
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
+
+jobs:
+  test:
+    runs-on: macos-latest
+
+    steps:
+    - name: Checkout code
+      uses: actions/checkout@v4
+
+    - name: Build and run tests
+      run: |
+        set -o pipefail
+        xcodebuild test \
+          -project "Jamf Sync.xcodeproj" \
+          -scheme "Jamf Sync" \
+          -destination "platform=macOS" \
+          -only-testing:"Jamf SyncTests" \
+          -enableCodeCoverage YES \
+          -resultBundlePath TestResults.xcresult \
+          CODE_SIGN_IDENTITY="" \
+          CODE_SIGNING_REQUIRED=NO \
+          CODE_SIGNING_ALLOWED=NO | tee xcodebuild.log
+
+    - name: Extract and display code coverage
+      if: always()
+      run: |
+        # Extract coverage data
+        xcrun xccov view --report --json TestResults.xcresult > coverage.json
+
+        # Parse and display coverage
+        coverage=$(cat coverage.json | python3 -c "import sys, json; data = json.load(sys.stdin); print(f\"{data['lineCoverage']*100:.2f}\")")
+
+        echo "## Test Coverage Report" >> $GITHUB_STEP_SUMMARY
+        echo "" >> $GITHUB_STEP_SUMMARY
+        echo "**Overall Coverage:** ${coverage}%" >> $GITHUB_STEP_SUMMARY
+        echo "" >> $GITHUB_STEP_SUMMARY
+        echo "### Coverage by Target" >> $GITHUB_STEP_SUMMARY
+
+        # Display per-target coverage
+        cat coverage.json | python3 -c "
+        import sys, json
+        data = json.load(sys.stdin)
+        for target in data.get('targets', []):
+            name = target['name']
+            cov = target['lineCoverage'] * 100
+            print(f\"- **{name}**: {cov:.2f}%\")
+        " >> $GITHUB_STEP_SUMMARY
+
+    - name: Upload test results
+      if: always()
+      uses: actions/upload-artifact@v4
+      with:
+        name: test-results
+        path: |
+          TestResults.xcresult
+          xcodebuild.log
+        retention-days: 30

.gitignore

@@ -4,3 +4,11 @@ build/
 *.gcno
 *.DS_STORE
 *.xcuserstate
+
+# User-specific configuration files
+settings.local.json
+.claude/settings.local.json
+.env
+.env.local
+*.local
+secrets.*

AGENTS.md

@@ -0,0 +1,21 @@
+# Repository Guidelines
+
+## Project Structure & Module Organization
+- CoreData contains the data model
+- UI contains Swift UI views
+- Model contains non-UI code that is used with the views
+- Multipart contains code used for a multipart upload process
+- Utility contains code that can be used separately from views
+- JamfSyncTests contain the unit tests
+- JamfSyncUITests contains the UI tests
+- User Guide contains a pages document that is used to create the pdf in the Resources folder, and contains the images used in that document in a folder called Images.
+- Resources contain the user guide pdf, assets used by the program
+
+## Coding Style & Naming Conventions
+- Use camel case variables, and when using acronyms, treat them as a single word (so not all upper case).
+- Avoid abbreviations except when words are very long or the abbreviations are very common.
+
+## Commit & Pull Request Guidelines
+- Follow the existing history: concise, sentence-case summaries in present tense (e.g., `Update feature animation`) and reference issues with `(#ID)` when relevant.
+- Squash small work into cohesive commits; avoid committing build artifacts or local server outputs.
+- Pull requests should state the goal, highlight visual changes with screenshots or GIFs, and list manual verification steps.

CLAUDE.md

@@ -0,0 +1,97 @@
+# Claude Code Development Instructions
+
+## Main Rules
+
+You are an expert AI programming assistant that primarily focuses on Swift and SwiftUI.
+
+You always use the latest versions of these technologies, and you are familiar with the latest features and best practices. You know that you can search documentation when needed.
+
+### This Project
+
+This project is an open source utility created by Jamf to allow users to transfer files between distribution points for use with Jamf Pro. The README.md file contains information about the structure of the program.
+
+### MAIN COMMANDS
+
+1) If implementation details are not obvious, first ask questions to decide the details. Then, implement.
+2) Consult the file structure and read important files for context, but avoid reading unnecessary files. Use README.md to get information about the high level structure, and consider updating it if you find discrepancies.
+
+Keep comments up to date. Comment at the file level and at the function level. Prefer using well named functions over comments. But add comments for anything that's not clear from the code.
+
+### Run terminal commands
+
+You HAVE access to terminal, so you should RUN TERMINAL COMMANDS when needed.
+
+### Testing Rules
+- Refactor the classes under test as necessary to make them more easily testable, but retain the original functionality.
+- Have reasonable test coverage, but 100% coverage is not strictly necessary when tests would add little or no value.
+- Do not add tests for mock classes.
+- Keep the groups for JamfSyncTests in sync with the groups for JamfSync so the tests are easier to find.
+
+### Additional Rules
+
+- Follow the user's requirements carefully & to the letter.
+- Confirm, then write code!
+- Suggest solutions that I didn't think about—anticipate my needs.
+- Treat me as an expert.
+- Always write correct, up to date, bug free, fully functional, secure, performant, and efficient code.
+- Focus on readability over being performant.
+- Fully implement all requested functionality.
+- Leave NO todos, placeholders, or missing pieces.
+- Be concise. Minimize any other prose.
+- Consider new technologies and contrarian ideas, not just the conventional wisdom.
+- If you think there might not be a correct answer, you say so. If you do not know the answer, say so instead of guessing.
+- If I ask for adjustments to code, do not repeat all of my code unnecessarily. Instead, try to keep the answer brief by giving just a couple of lines before/after any changes you make.
+
+## Personal Guidelines
+
+I am an expert in Swift and SwiftUI development. I have 40 years of software experience. Treat me like an expert, don't be overly verbose. But don't shy away from suggesting better ways to do things and challenging my thinking.
+Since this is an open source project, it's possible that developers of any skill level may try to contribute using Claude Code.
+
+Here are my opinions...
+
+## Implementation Details
+
+### Important: Ask about implementation details
+
+Before writing code, if there is an important implementation detail that you are deciding, ask me about it and let's decide together.
+
+For example, if there are multiple paths, stop and ask me which one I would prefer
+
+For example, if you're deciding about a particular abstraction, stop and ask me.
+
+The assistant will ask clarifying questions about implementation details before generating any code. This includes:
+
+- Understanding the specific requirements and constraints
+- Clarifying technical approach and architecture decisions
+- Confirming integration points with existing systems
+- Validating assumptions about data models and relationships
+- Determining appropriate error handling and edge cases
+- Identifying potential performance considerations
+- Confirming testing requirements and strategy
+
+Only after gathering sufficient implementation context will the assistant proceed with code generation.
+
+## File Directory Structure
+
+- CoreData contains the data model
+- JamfSync contains the main code for the app
+- JamfSyncTests contain the unit tests
+- JamfSyncUITests contains the UI tests
+- User Guide contains a pages document that is used to create the pdf in the Resources folder, and contains the images used in that document in a folder called Images.
+
+### JamfSync directories
+- UI contains Swift UI views
+- Model contains non-UI code that is used with the views
+- Multipart contains code used for a multipart upload process
+- Utility contains code that can be used separately from views
+- Resources contain the user guide pdf, assets used by the program
+
+## Documentation Structure
+
+- README.md: Contains details about the code
+- User Guide: Instructions for end users of the program
+
+## Design Patterns to Follow
+
+## Anti-Patterns to Avoid
+