Building a GIF Editing App with Electron Using Claude Code + TDD # prompts/you_are_traveling_to_iceland.md Human: You are traveling to Iceland next week for a 5 day trip. What should you pack?
This page has been translated by machine translation. View original
Introduction
I needed to edit GIFs recorded on macOS. For purposes like applying mosaic to personal information or trimming unnecessary frames. Although existing tools could handle this, I wanted something simpler that focused on my specific needs, so I decided to create it.
I made a desktop application that can crop, apply mosaic, reduce frames, delete frames from GIF files, and export them as GIFs.
I had Claude Code implement this using Test-Driven Development (TDD). Even when major specification changes occurred, I could confidently address them while ensuring tests passed. This article describes that development experience.
How I Built It with Claude Code + TDD
The entire development was conducted in dialogue with Claude Code.
Requirements Definition and Planning
First, I communicated "the kind of app I wanted," and had Claude Code ask me questions to clarify. We identified ambiguous parts of the specifications, such as input formats, how to apply mosaics, whether Undo was needed, before creating a plan.
In the planning phase, I also confirmed "any concerns." It was helpful to consider potentially difficult-to-notice issues in advance, such as disk load during Undo operations, or compatibility between sharp (image processing library) and Electron's native modules.
TDD Cycle
Implementation proceeded with TDD for each phase, following this cycle:
- Red: Write tests first. Naturally, the tests fail.
- Green: Write minimal implementation to make tests pass.
- Refactor: Clean up while maintaining passing tests.
In the mosaic processing phase, I first defined tests like "pixels within the specified rectangle should be uniformly blocky" and "pixels outside the rectangle should remain unchanged," then implemented accordingly.
Handling Specification Changes
Midway through development, there was a specification change from "MP4 input to GIF input." Normally, understanding the scope of impact would take time, but thanks to TDD, the adaptation was smooth.
The procedure was as follows:
- Change test fixtures from sample MP4 to sample GIF
- Modify test expectations to GIF prerequisites (at this point, all tests fail)
- Fix implementation to make tests pass
The tests accurately told me "what was broken," so I didn't have to worry about missing changes.
When a bug occurred where playback speed changed after frame reduction, this too was smoothly fixed by adding tests. I wrote a test specifying "the duration of the GIF after reduction should be the same as the original," and fixed it by modifying FFmpeg option settings.
Technology Stack
| Category | Technology |
|---|---|
| Application Shell | Electron |
| Language | TypeScript (strict) |
| GIF Processing | FFmpeg (ffmpeg-static) |
| Mosaic/Crop | sharp |
| Testing | Vitest |
It uses Electron's standard 3-layer structure (main process / preload / renderer). I adopted a destructive editing model that expands GIFs into frame-by-frame PNGs and applies edits directly to each frame. Undo/Redo is managed with differential backups in a stack on the file system.
For implementation details, please refer to the repository.
Conclusion
By letting Claude Code implement with TDD, tests functioned as a safety net during specification changes and bug fixes. Simply telling AI to "write tests first" and seeing the Red → Green → Refactor cycle in action was a fresh development experience. I felt that combining Claude Code with TDD could be applied to other projects beyond GIF editing.
GitHub Repository: https://github.com/takumi-koshii/simple-gif-editor