This pull request adds support for noexcept member functions to the C++ mocks template. It also tags the member functions of the Shape class hierarchy as noexcept, allowing us to test that the mock classes are generated with appropriate noexcept specs.
I had to remove a test that throws when no expected value is set for the mock object, as this would violate the noexcept specification and cause the test to terminate.
Closes [github issues]
Closes #260.
Where should the reviewer start?
Begin by determining whether we are happy with the removal of the test for the unset mock objects. From there, inspect the template and Shape.h to verify correct implementation.
Ideas that were considered and discarded
It occurred to me that we could return some proxy object that has implicit conversion to the correct return type, which would throw if the expected value was not set. I didn't explore this route as it would add (likely) unnecessary complexity.
Possible future work
Reinstate the throw-if-no-expected-value-set test with another class / class hierarchy. Shape is used widely and is a good candidate for noexcept testing. Perhaps the Animal classes could be used to test the unset-value mock behaviour?
What does this PR do?
This pull request adds support for
noexcept
member functions to the C++ mocks template. It also tags the member functions of theShape
class hierarchy asnoexcept
, allowing us to test that the mock classes are generated with appropriatenoexcept
specs.I had to remove a test that throws when no expected value is set for the mock object, as this would violate the
noexcept
specification and cause the test to terminate.Closes [github issues]
Closes #260.
Where should the reviewer start?
Begin by determining whether we are happy with the removal of the test for the unset mock objects. From there, inspect the template and
Shape.h
to verify correct implementation.Ideas that were considered and discarded
It occurred to me that we could return some proxy object that has implicit conversion to the correct return type, which would throw if the expected value was not set. I didn't explore this route as it would add (likely) unnecessary complexity.
Possible future work
Reinstate the throw-if-no-expected-value-set test with another class / class hierarchy. Shape is used widely and is a good candidate for
noexcept
testing. Perhaps theAnimal
classes could be used to test the unset-value mock behaviour?