I’ve looked over the automation guide pages, but I don’t see anything about mocking, stubbing, spying, etc. Are these supported when adding tests? Are there any project examples that include tests with mocking?
My testing experience comes from Node.JS and PHP. Is there something else (not part of the UE 4 code) I should use for mocking in C++ that will work with the UE automation? What about when testing blueprints?
I have the same question! any updates?
bump - same here
bump - same here. I’ve been looking at the Unreal Tournment tests and cannot find anything obvious to denote if there is a built in mocking framework. It seems there isn’t. I’m going down the route of trying out: GitHub - eranpeer/FakeIt: C++ mocking made easy. A simple yet very expressive, headers only library for c++ mocking. - I will write instructions on how to implement it if it’s possible.
Would be nice to have an official answer on this
There is no official framework at this time. We are actively making improvements to our automated testing tools and while mocking has come up in discussions it hasn’t been put on the roadmap at this time.
Really glad a developer has replied to this.
But please please please add more support for unit testing!!! Mocking especially, and examples with how to unit test basic behavior like testing if a character moves forward, jumps, etc.
Thank you!
We’re definitely aware there’s tons of room for improvement in our automation and testing tools. It will take some time, but improvements are coming.
Hi @LordBongoCat, bumping into this as I’m digging around for a good solution to speed up writing mocks for my unit tests in Unreal. Our project is fairly unit-test driven, with hundreds of them right now, and it’s getting to be a bear to write and maintain all of these mocks when there are great mock generation tools. Any update or word on more tools coming our way for mock creation?
Hi @dangoes2 ,
We are currently working on a new framework for automated testing and will release this plugin on Github in a few weeks.
It will also support unit tests for blueprints.
Would you be interested in testing the plugin?
Could you share more details about your current workflow, specifically how you organize, write and maintain your mocks? The insights from your experience would be of great benefit to the development of our framework and could lead to more efficient testing procedures for Unreal Engine projects. In addition, any tools or methods you have found to be effective would be valuable to know.
I look forward to your response and the possibility of a mutually beneficial exchange of ideas.
@Ramon_Janousch
Do you have any update on the plugin?
I’m very interested in TDD in Unreal Engine and in the past I wrote some articles on using unreal tests in a project taking into account ticks, PIE sessions, editor clicks, networking, etc.
Maybe some of the utilities mentioned there are useful for you and your team to use so I’ll leave them here 
Jenkins, CI and Test-Driven Development → this one is about having a simple CI solution using Jenkins. Also with a repo
And then these talking about things to take into account when testing:
Considerations On Testing UE4 Classes Part I: Worlds, Ticks and Forces
Considerations On Testing UE4 Classes Part II: Editor clicks and Gamepad/Keyboard button presses
Considerations On Testing UE4 Classes Part III: Replication
This is a repo with a small game using the things mentioned in the articles above: ProjectR
I have a slightly different opinion on what to mock:
You should mock things that are non-deterministic, and nothing else.
You need a mock clock. You need a mock file system (probably, although with proper test isolation maybe not.) You need a mock network. You need a mock database. You may need a mock graphics device, and you almost certainly need a mock input device.
However, you don’t need a mock for the service that runs on the other side of the network. Just run the actual code of that service, and just plumb it through using the mock network. It’s all in process, it’s all deterministic, it’s all testable and debuggable.
You don’t need a mock texture streaming manager – run the real thing, just have it talking to the mock file system and the mock graphics device (and maybe mock clock, for time based purging.)
You then write simple functional tests for each of the mocked subsystems, run the same tests on both the mock and the real device to verify they behave the same, and then all the rest of your code tests against the small set of mocks. Because RAM and CPUs are deterministic, you should run your tests with as much code as possible in the loop.
Some people call this “integration testing,” but I feel that it’s not, in the sense that it’s deterministic and debuggable and fast – anything that sits in CPU and RAM should not take a meaningful amount of time in a test.
People who come from dynamically-patchable languages tend to not have this approach, and there’s often a fair bit of friction and discussion to get on the same page, but in practice, you get much better test coverage (and thus, much earlier detection when expectations get violated) when you keep the mocks to a bare minimum.