C++ Projects, CMake, and Testing

Source files organize definitions; headers expose interfaces; a build target groups sources, compiler requirements, include paths, and dependencies into one library or executable. Splitting files does not create architectural value by itself—the target boundary states reusable ownership.

A small project can use a domain library, console executable, and test executable. This lets tests call rules without linking terminal behavior and lets another interface reuse the same library later.

task-tracker/
CMakeLists.txt
include/task_tracker/task.hpp
src/task.cpp
app/main.cpp
tests/task_tests.cpp

Put declarations needed by callers in headers and implementation details in source files. Use include guards or #pragma once, include what the header itself needs, and avoid broad namespace imports in headers because they affect every includer.

Changing a public header can rebuild many translation units. Keep interfaces focused and prefer forward declarations only when they are valid and genuinely simplify dependencies.

Modern CMake attaches requirements to targets. target_compile_features requests a language level, target_include_directories publishes include paths, and target_link_libraries states dependencies. Configure into a separate build directory so generated files do not mix with source.

cmake_minimum_required(VERSION 3.20)
project(TaskTracker LANGUAGES CXX)

add_library(task_tracker src/task.cpp)
target_include_directories(task_tracker PUBLIC include)
target_compile_features(task_tracker PUBLIC cxx_std_20)

add_executable(task_tracker_app app/main.cpp)
target_link_libraries(task_tracker_app PRIVATE task_tracker)

enable_testing()
add_executable(task_tracker_tests tests/task_tests.cpp)
target_link_libraries(task_tracker_tests PRIVATE task_tracker)
add_test(NAME task_tracker_tests COMMAND task_tracker_tests)

A focused test arranges input, calls one public behavior, and checks the observable result. Boundary cases concentrate defects: just below, exactly at, and just above a threshold. See a new test fail for the expected reason before trusting its success.

Assertions from cassert are enough to learn the structure but can be disabled in release builds and provide limited reporting. A test framework adds discovery, fixtures, parameterized cases, and diagnostics. Keep tests independent of order, working directory, network, and private implementation details.