I'm fairly new to programming and want to understand how professional software development should be approached, independent of any particular language or technology stack.
I've been working on a small C-based raycasting game engine as a hobby project. It currently works, but I'm trying to imagine developing a serious game on top of it. Should I focus on getting the main functionality working first and add automated tests and CI/CD later, or should those be developed alongside the features? How should a project be structured so that it remains testable? Should every piece of game logic and rendering code be tested, or are some parts better tested through larger scenarios?
I'm also beginning a long-term blog project and would like to build it in a professional, maintainable way rather than having to redesign everything later.
3 Answers
Start by getting a small, useful version working, but don’t treat testing and structure as something that must wait until the end. Add a basic build process, version control, and a few automated checks early, then expand them as the project grows. The most important design step is deciding who the software is for and validating that you’re building something useful. It’s easy to spend a lot of time polishing architecture before you know what the product actually needs.
You usually don’t need to test every line or implementation detail. Focus on stable boundaries and observable behavior: give a function or module an input, then verify its output or effect. Keep core rules and calculations separate from rendering, file access, input handling, and other external systems. That makes the important logic easy to test without requiring a graphics window or a complete running game. Tests should protect behavior that matters, not make every refactoring painful.
Games often change quickly, so extensive unit-test coverage can become expensive to maintain, especially for presentation and rendering code. A practical balance is to unit-test deterministic systems such as movement rules, collision detection, parsing, save data, and gameplay calculations. Then use integration or scenario tests for larger flows, along with performance benchmarks and scripted playthroughs when they provide value. For an early hobby project, keep the test suite small and useful, and increase coverage as the code and requirements become more stable.
That makes sense. I was imagining that professional development meant designing the entire architecture and test strategy before writing much of the actual product, but starting with a small working slice seems more realistic.