Now, before we delve into the specifics of the test itself, you probably want to understand how tests are structured using GameDriver. The basic structure of a test is as follows. We have a setup section that will be executed at the beginning of the test. This is where we typically include methods of connecting to the different platforms we wish to test, along with any logic required to determine which to use. We also have a corresponding teardown section which, as the name suggests, handles any teardown methods such as disconnecting from the device or editor, and cleaning up any files we create. Then we have the tests themselves. These are typically separated by the functionality we want to cover and can be as large or small as necessary. However, it's best practice to keep these as small and relatively self-contained as possible. By 'self-contained', we mean that we want each test to be able to run independently of each other. That way, if a single test fails, it doesn't affect the entire run, unless something catastrophic happens, like the application crashing. Keeping that in mind, each test should include a setup, one or more actions, and some sort of validation to determine whether or not we achieved the expected results. The setup might involve determining where in the execution process we are, setting or changing the values that we need to prepare for the test itself. This could be loading a scene, positioning a player to a specific location, or toggling a setting within the game engine. The tests can be any sort of action or change, such as user inputs or changing a setting. It doesn't need to be limited to actions that a user would perform but can be any sort of change to the state of the application where we want to observe the outcome.
Lastly, we have the validation phase. This is where we check something to determine whether or not our action had the expected results. For example, if our test is registering a new user, the validation step would be to check somewhere in the system that the new user was created with the desired properties. This is essentially the structure of all automated tests and some higher-level test frameworks. The implementation of test steps can be abstracted in a way that the user only writes simple, 'given-then-when' types of steps, which is just another way of defining these parts of the test. It means that 'given' a set of conditions, 'then' we should see a certain result 'when' these actions or changes are made. A basic example might be a test where we're waiting for an object to appear in a scene. You can see here through the api.WaitForObject, but we'll delve deeper into that structure later. In this case, we're looking for an object named 'button'. Once that button exists, this task or this step is complete. We would then click on that button using the LEFT mouse button for 30 frames. Then, we're going to wait one second for the application to load or we could anchor our next step on another WaitForObject or WaitForObject value. But we'll delve deeper into that in a moment. Finally, we're going to assert, which is our check for this test, that the field of a specific object, in this case, the 'TextMeshProUGUI' field, provides an exact value of 'success'. Otherwise, the tests will fail and indicate that the text doesn't match. Before we get into too much detail here, essentially what we're saying is that we have a start, which is the 'wait for object', the inputs, which involve clicking on that specific object, and then the outcome, which is that we see the 'success' text appear on the screen.
Comments are closed.