What is short-circuit evaluation in C++?
Short-circuit evaluation is a behavior of logical operators in C++ where the second part of an expression is evaluated only if it is necessary to determine the final result.
For example, in an expression using the logical OR operator, if the left-hand side already evaluates to true, the right-hand side is never executed because the entire expression must already be true.
if (is_admin || hasPermission())
{
// ...
}
If is_admin is true, the function hasPermission() will never be called. The same rule applies to the logical AND operator in the opposite direction: if the left-hand side is false, the right-hand side is skipped. Such behavior is often beneficial because it avoids unnecessary work.
How does this matter in practice?
Short-circuit evaluation becomes especially important in unit tests when mocking calls used as parts of if statements. Consider the following code:
class PermissionService
{
public:
virtual bool HasPermission() = 0;
};
bool CanAccess(bool is_admin, PermissionService& service)
{
if (is_admin && service.HasPermission())
{
return true;
}
return false;
}
At first glance, one of the unit tests testing the above code could look like this:
class MockPermissionService : public PermissionService
{
public:
MOCK_METHOD(bool, HasPermission, (), (override));
};
TEST(CanAccessTest, ReturnsTrueForAdmin)
{
StrictMock<MockPermissionService> service;
EXPECT_CALL(service, HasPermission()).WillOnce(Return(true));
EXPECT_FALSE(CanAccess(false, service));
}
However, when you run this test, you'll see that it failed with the following error:
Actual function call count doesn't match EXPECT_CALL(service, HasPermission())...
Expected: to be called once
Actual: never called - unsatisfied and active
How is this possible that HasPermission() was never called if we clearily see it in the tested code? The answer is: short-circuit evaluation.
Since is_admin is false, C++ short-circuit evaluation stops the expression immediately. The call to service.HasPermission() is never executed and as a result the mocked method is never called, so the EXPECT_CALL expectation is not satisfied.
The failure is not caused by incorrect production code. The issue is that the test assumes both sides of the condition are evaluated, while the language guarantees that only the necessary side is executed.
The correct test should reflect the actual execution path:
TEST(CanAccessTest, ReturnsTrueForAdmin)
{
StrictMock<MockPermissionService> service;
EXPECT_TRUE(CanAccess(false, service));
}
Or if we specifically want to verify the permission check path, we should make the first condition evaluate to false:
bool CanAccess(bool is_admin, PermissionService& service)
{
if (service.HasPermission() && is_admin)
{
return true;
}
return false;
}