Unit tests for a simple game loop using SDL - c++

Question

Background
This is my first time writing unit tests in C++. I am using Catch2 as a test framework and I have 2 projects set up in my Visual Studio solution: one for my application, and one for the tests.
I have a simple game loop that I want to test. Something like this:
Application.h
#ifndef APPLICATION_H
#define APPLICATION_H
namespace Rival {
class Application {
public:
void start();
};
} // namespace Rival
#endif // APPLICATION_H
Application.cpp
#include "pch.h"
#include "Application.h"
#include <SDL.h>
namespace Rival {
void Application::start() {
Uint32 nextUpdateDue = SDL_GetTicks();
while (!exiting) {
Uint32 frameStartTime = SDL_GetTicks();
if (nextUpdateDue <= frameStartTime) {
// Update the game logic, as many times as necessary to keep it
// in-sync with the refresh rate.
while (nextUpdateDue <= frameStartTime) {
state->update();
nextUpdateDue += TimerUtils::timeStepMs;
}
state->render();
} else {
// Sleep until next frame is due
Uint32 sleepTime = nextUpdateDue - frameStartTime;
SDL_Delay(sleepTime);
}
}
}
} // namespace Rival
Problem
The problem is the #include <SDL.h>.
I want to be able to mock methods from this header, for example SDL_GetTicks().
I don't want to actually include SDL, if I can help it; I want to keep my unit tests lightweight and free from any window creation / rendering code.
How is this normally accomplished?

Answer 1

The answer is to apply the Fundamental Theorem of Software Engineering, which says that you can solve virtually any problem by adding a new layer of abstraction.
Here that means you wrap your SDL calls in a class that you can swap out at test time. Define an interface (abstract base class), then implement one derivative that uses SDL, and implement another (or use a mock) for tests. Only the SDL implementation will know about SDL, so the tests will not even include or link it.
BTW, for a great summary of testing in C++, see this episode of CppCast on designing for test.

Answer 2

In the end I solved this by stubbing the library functions I was using. You can find my commit with the working test implementation here.
This is somewhat similar to #metal's suggestion, but instead of adding a new layer of abstraction I relied on the fact that my test project did not include the library headers, which meant that I was free to provide my own substitutions for use in the tests.
Maybe the documentation I produced in the process will help someone else:
The test project includes all headers defined by Main-Project, but does not include the headers from third-party libraries. This is to help keep the tests lightweight; we do not want to create an OpenGL context every time we run our tests.
This means that we have to provide stub implementations for any third-party definitions that we depend upon. Stub or mock implementations of Main-Project definitions can also be provided for files that depend heavily on third-party libraries (e.g. Texture). Other source files from Main-Project can be directly included in the test project, as required.
To keep the project organised, several filters have been created:
Test Framework: Files required to get the tests to run.
Source Files: Unmodified source files under test, imported directly from Main-Project.
Test Doubles: Test-only implementations of Main-Project headers.
Tests: The tests themselves.
As an aside, the Catch2 framework has been excellent so far, and has added no extra complexity whatsoever.