It is / or should be less tedious than a writting a custom class with the return values you need for everything.
I still recomend hand written fakes - but only because and if they model real behavior without the unwanted effects. I find my handwritten cods often has more lines of test code to ensure it works than the real implementation.
> model real behavior without the unwanted effects.
That's how I was looking at this since that's the experience I've had with mocks. For example, mocking an API to test a library that uses that API without incurring the real usage costs everytime the tests are ran. Going back over the github again, I can see this being useful if you have to fake a lot of APIs. Though my personal preference would always be to limit mocks as much as possible even with that framework available.
Most side effects are not a problem (or should not be).
Years ago we decided that the data directory would be changeable so we call get data directory - that call is an easy constant in production not worth testing, but in test mode it is a complex call to make temp dir, setup the default contents (which might be real default or a test specific situation), then destroy it when the test is done. So a lot of tests are needed to get it right (everyone uses it)- however because we have this we can use a sqlite in our tests thus saving needing to mock the database: side effects from database manipulation no longer matter.
I do a similar thing for dbus, want to use the systembus - in tests I intercept your open call and launch new server on a different port just for this test. Again a lot of tests.
For time I intercept all the timer and get time calls. When in tests I have an advanceTime function that advances all the timers the intended amount and takes action If you advance 100ms a 10ms timer will fire 9-10 times before the 100ms timer you (9-10 because the last time both timers will fire and which is first depends)
The above is real world things I've done and found very useful for long enough that I'm trying to spread it. I believe that it would help everyone to start doing the same.
I like that they have the verify as a separare / latter step. Most users of google mock see a mock call and assume that they need to force the call - thus if you change the implementation you are breaking tests but the real code still works because that should be an implementation detail.
Yikes. "Broken with optimizations" means "broken" to me. Don't screw around with undefined behavior; either you had better avoid it, or your circumvention of the compiler had better be so airtight that it still works with optimizations.
I can’t remember ever seeing a bigger red flag on a C++ library than this. Even leaving aside the implications of UB (where I agree with you), does this mean I can’t run my test suite in release mode? What if it’s slow to run? What if there’s a bug that only happens in optimized builds?
Those are not, in general terms, words to live by. In video games, of all things, it is usual to prevent certain code paths from being optimized for actual enforcement of security measures. Compilers are the ones taking optimizations a bit too far.
It has a overlapping name with a Microsoft framework,
https://learn.microsoft.com/en-us/visualstudio/test/isolatin...
Writing the actual code to implement the interface would be less code than the example using this library.
I can not imagine when this type of library becomes useful. What's a usage example for this? What do you gain over rolling your own?
It is / or should be less tedious than a writting a custom class with the return values you need for everything.
I still recomend hand written fakes - but only because and if they model real behavior without the unwanted effects. I find my handwritten cods often has more lines of test code to ensure it works than the real implementation.
> model real behavior without the unwanted effects.
That's how I was looking at this since that's the experience I've had with mocks. For example, mocking an API to test a library that uses that API without incurring the real usage costs everytime the tests are ran. Going back over the github again, I can see this being useful if you have to fake a lot of APIs. Though my personal preference would always be to limit mocks as much as possible even with that framework available.
Most side effects are not a problem (or should not be).
Years ago we decided that the data directory would be changeable so we call get data directory - that call is an easy constant in production not worth testing, but in test mode it is a complex call to make temp dir, setup the default contents (which might be real default or a test specific situation), then destroy it when the test is done. So a lot of tests are needed to get it right (everyone uses it)- however because we have this we can use a sqlite in our tests thus saving needing to mock the database: side effects from database manipulation no longer matter.
I do a similar thing for dbus, want to use the systembus - in tests I intercept your open call and launch new server on a different port just for this test. Again a lot of tests.
For time I intercept all the timer and get time calls. When in tests I have an advanceTime function that advances all the timers the intended amount and takes action If you advance 100ms a 10ms timer will fire 9-10 times before the 100ms timer you (9-10 because the last time both timers will fire and which is first depends)
The above is real world things I've done and found very useful for long enough that I'm trying to spread it. I believe that it would help everyone to start doing the same.
I like that they have the verify as a separare / latter step. Most users of google mock see a mock call and assume that they need to force the call - thus if you change the implementation you are breaking tests but the real code still works because that should be an implementation detail.
"On GCC, optimization flag O2 and O3 are not supported. You must compile the test project with -O1 or -O0."
Sounds like they are patching objects in memory. Trompeloeil, for example, doesn't do that.
Yikes. "Broken with optimizations" means "broken" to me. Don't screw around with undefined behavior; either you had better avoid it, or your circumvention of the compiler had better be so airtight that it still works with optimizations.
I can’t remember ever seeing a bigger red flag on a C++ library than this. Even leaving aside the implications of UB (where I agree with you), does this mean I can’t run my test suite in release mode? What if it’s slow to run? What if there’s a bug that only happens in optimized builds?
That’s gonna be a big no from me, dawg.
Those are not, in general terms, words to live by. In video games, of all things, it is usual to prevent certain code paths from being optimized for actual enforcement of security measures. Compilers are the ones taking optimizations a bit too far.
Seems very inspired by gmock. Wondering if there's a comparison somewhere?
Great project, thank you!