DEV Community: Christian Blos

The Player Setup Endpoint – Let the Frontend run Backend code

Christian Blos — Mon, 04 Jan 2021 18:40:23 +0000

This article was originally published on the InnoGames Techblog and can be found here.

Introduction

While developing a game it’s often required to put a player into a certain state or change the player’s progression. This is especially necessary if we want to test new game features or bug fixes. Regardless of whether we test it manually or write an automated test, we always need a player account who meets all the requirements and conditions to test the feature.

When testing manually, we usually make use of in-game cheats that we have implemented just for testing purposes. E.g. to give out resources, immediately finish a timer or unlock a feature.

In our automated frontend tests (end to end tests) the test runner acts like a real player. For example, it simulates a button click and waits for something to appear on the screen. Also here we usually use in-game cheats to change the player’s progression before running the actual tests.

Then we have backend system integration tests. They have full access to the game’s backend code which makes it possible to reuse Entity and Repository classes from the game code in order to set up a player. This is the fastest approach because they directly manipulate the database without the overhead of making several cheat requests. We abstracted the player setup into a builder-like API that allows us to define the whole player state by configuring a single object (You can find more information about this architecture in an earlier blog post: How to make your tests more readable and maintainable). Here’s an example of what the player setup looks like in a backend test:

@Test
public void testCollectProduction() {
   buildScenario(scenario -> scenario
      .withPlayer(player -> player
         .withResource(ResourceConstants.COINS, 100)
         .withCity("MainCity", city -> city
            .withBuilding("SomeProductionBuilding", building -> building
               .withProduction(production -> production
                  .withResource(ResourceConstants.COINS)
                  .withAmount(20)
                  .withFinishNow()
               )
            )
         )
      )
   );

   // ... test action and assertions are here ...
}

At some point we wondered if we couldn’t use the same thing in frontend tests instead of using cheats, as the cheats are very limited. So we came up with a solution that allows us to use the exact same player setup code in frontend tests without additional effort! The “Player Setup Endpoint”.

The Player Setup Endpoint

To demonstrate this endpoint I created a demo project where we can configure a players name, level and equipment through the player setup endpoint. You can find the full source code on GitHub. It is written in Java using Spring Boot. Let’s start with a very simple example. This is a plain HTTP request to the endpoint:

POST /setup-player HTTP/1.1
Host: localhost:8080
Content-Type: text/plain
Accept: application/json

player
    .withName("Hero")
    .withLevel(2)

As you can see, the request body actually contains code. It’s the same code that we use in our backend tests. We configure a player object by setting the players name to “Hero” and the level to 2.

The demo project also provides an endpoint to show the current state of the player as an SVG image. Just open http://localhost:8080/player in a browser. For our Hero with level 2 you will see this image:

To give the player a weapon, simply call withWeapon() on the player object. The weapon itself can be configured the same way by using “with…”-methods on the weapon object.

POST request to /setup-player:

player
    .withName("Hero")
    .withLevel(2)
    .withWeapon(weapon -> weapon
        .withType(Weapon.Type.SWORD)
        .withAttackPoints(10)
    )

GET request to /player:

Now let’s configure everything that the demo project supports:

POST request to /setup-player:

player
    .withName("The Mighty")
    .withLevel(99)
    .withWeapon(weapon -> weapon
        .withType(Weapon.Type.AXE)
        .withAttackPoints(20)
        .withColor("#26639b")
        .entityRef(ref("weapon"))
    )
    .withHeadgear(headgear -> headgear
        .withType(Headgear.Type.HELMET)
        .withDefense(35)
        .withColor("#711284")
        .entityRef(ref("helmet"))
    )

GET request to /player:

You might be wondering about the entityRef() calls. The entityRef() method accepts a reference holder object that will be filled with the entity that is created during the player setup. We heavily use this in the backend tests to be able to access the newly created entities afterwards (You can read more about it in the blog post I mentioned above). In our endpoint we use it together with the ref() function which is a special feature of the player setup endpoint. It creates a reference holder object with the passed name assigned to it. The response body then contains all references that are created that way. In the last example we defined two references, “weapon” and “helmet”. Here’s how the response looks like:

{
    "weapon": {
        "id": "13aafbad-54be-425f-a27a-030935d7852a"
    },
    "helmet": {
        "id": "b9b5fa2d-0a00-40b3-b8c3-c4468943ceff"
    }
}

It returns a JSON object with the reference name as property and the entity as value. In our case we only return the “id” field of the entities. Of course you could return the whole entity instead, but the ID should be sufficient in most cases. Knowing the generated IDs can be very helpful for frontend tests in order to do further actions on the new entities.

How it works under the hood

In order to execute custom code through the endpoint, we can take advantage of the Groovy language. Fortunately, Groovy is compatible with Java syntax which allows us to just copy code parts from our backend tests and paste it into the request body. That means the request body is actually a Groovy script!

To integrate Groovy in our Java application, we make use of the groovy package. It comes with a Groovy Shell that is not only able to execute Groovy scripts, but also has the ability to share objects between Java and the Groovy script. The following picture illustrates how the endpoint works:

We create a GivenPlayer object that is a simple data object with a builder-like API. Then we pass this object to the Groovy shell so it is accessible by the Groovy script. Afterwards we execute the script from the request body to configure the player object. When the script execution is done, we can use the same object to finally set up the player.

Here’s the full Java code of the Controller method:

@PostMapping(value = "/setup-player", produces = MediaType.APPLICATION_JSON_VALUE)
public String setUpPlayer(@RequestBody String request) throws JsonProcessingException {
   Player player = playerRepository.getCurrentPlayer();

   // Create sandboxed groovy shell
   var groovyShell = groovyShellFactory.createSandboxShell();

   // Set player property that can be configured inside the groovy script
   var givenPlayer = new GivenPlayer();
   givenPlayer.setEntity(player);
   groovyShell.setProperty("player", givenPlayer);

   // Run requested groovy script which configures the givenPlayer object
   groovyShell.evaluate(request);

   // Use givenPlayer object to set up the player
   playerSetup.setUp(givenPlayer);

   // Return entities that were referenced in the groovy script
   return objectMapper.writeValueAsString(groovyShell.getProperty("references"));
}

I won’t go into detail about how the GivenPlayer object or the playerSetup.setUp() method works. You can find more information about the idea in the blog post I mentioned earlier or have a look into the code on GitHub. In general the playerSetup.setUp() method takes care of creating the real entities by reading the GivenPlayer object.

Let’s focus on how the Groovy Shell is created. Here’s a simplified version of the GroovyShellFactory:

var sandboxClassLoader = new GroovySandboxClassLoader(getClass().getClassLoader());

var compilerConfig = new CompilerConfiguration();
compilerConfig.addCompilationCustomizers(new GroovySandboxImportCustomizer());
compilerConfig.setScriptBaseClass(PlayerSetupScript.class.getName());

var groovyShell = new GroovyShell(sandboxClassLoader, compilerConfig);
groovyShell.setProperty("references", new HashMap<>()); // used to store the references

The configuration of the Groovy Shell contains three custom components. A ClassLoader, an ImportCustomizer and a script base class.

ClassLoader

We use a custom class loader in order to restrict access to classes inside the Groovy script. Even though the endpoint should only be enabled in the test environments it is important to keep an eye on the security aspects. Otherwise the endpoint would be able to break the game in many different ways. Here’s the implementation of the GroovySandboxClassLoader:

public class GroovySandboxClassLoader extends ClassLoader {

   public GroovySandboxClassLoader(ClassLoader parent) {
      super(parent);
   }

   @Override
   protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
      if (name.startsWith("java.")
         || name.startsWith("groovy.")
         || name.startsWith("org.codehaus.groovy.")
         || name.equals(PlayerSetupScript.class.getName())
         || GroovySandboxClassWhitelist.getWhitelist().containsKey(name)) {
         return super.loadClass(name, resolve);
      }
      return null;
   }

}

In order to get the Groovy Shell working, we have to allow access to the groovy packages as well as the base script class. In addition we just allow all java classes in order to use basic classes like String. Of cause you could whitelist those as well if you want to have it more secure. The actual whitelist of our own classes is implemented in a separate GroovySandboxClassWhitelist class, because we also use this whitelist in the ImportCustomizer. Here’s a simplified version of the whitelist class:

public class GroovySandboxClassWhitelist {

   // Mapping of "Class name" -> "Alias" (We need the alias for the ImportCustomizer)
   @Getter
   private static final Map<String, String> whitelist = new HashMap<>();

   static {
      addWithAlias(GivenPlayer.class);
      addWithAlias(GivenWeapon.class);
      // ...
   }

   private static void addWithAlias(Class<?> clazz) {
      whitelist.put(clazz.getName(), clazz.getSimpleName());
   }

}

In the demo project we just hard coded the whitelist to keep it simple. However, this would be too much maintenance effort in a larger application. In our real game application we are using the classgraph package to search for classes that should be whitelisted.

ImportCustomizer

Usually we have to add import statements to a Groovy script when we want to use a class. This is where the ImportCustomizer comes in handy. It allows us to automatically import classes, so we can omit the import statements. In our case we import all classes from the ClassLoader whitelist that have an alias defined.

public class GroovySandboxImportCustomizer extends ImportCustomizer {

   public GroovySandboxImportCustomizer() {
      super();

      GroovySandboxClassWhitelist.getWhitelist().entrySet().stream()
         .filter(entry -> !entry.getValue().isBlank())
         .forEach(entry -> addImport(entry.getValue(), entry.getKey()));
   }

}

That makes the GroovySandboxClassWhitelist as the source of truth for the ClassLoader and the ImportCustomizer. We just have to add a class there to make it available in the Groovy script and define an alias to automatically import it.

Script base class

The script base class provides additional behaviour to the Groovy script which is in our case only the ref() function that you saw in the example earlier.

public abstract class PlayerSetupScript extends Script {

   public AtomicReference<?> ref(String name) {
      var references = (Map<String, AtomicReference<?>>) getProperty("references");

      if (!references.containsKey(name)) {
         references.put(name, new AtomicReference<>());
      }

      return references.get(name);
   }

}

It creates a reference holder object and stores it in a property called “references” inside the Groovy script. The property can be accessed by the endpoint after the script execution to return all references in the response.

That’s it! Now we have created all classes that are necessary for our endpoint to execute Groovy scripts. You can find the full source code of the demo project on GitHub. For details of how the actual player setup is implemented I recommend you to check out the article I already mentioned or just have a look into the demo project.

Conclusion

With the power of Groovy, we found a way to make our player setup system accessible to the client.

Of course you have to keep the security aspects in mind. The class whitelist is already a good security factor, but it could still be possible to break the application when executing wrong code. Make sure to only enable this endpoint in the test environments. A downside is that there is no auto completion available for clients using this endpoint. I recommend preparing the configuration in a real Groovy script or somewhere in the backend code. Otherwise, syntax errors can easily occur.

However, it’s now sufficient if we implement the player setup of new game features once in the Backend. The Frontend tests or in-game cheats can make use of it immediately without any additional effort.

InnoGames is hiring! Check out open positions and join our awesome international team in Hamburg at the certified Great Place to Work®.

How to make your tests more readable and maintainable

Christian Blos — Mon, 12 Oct 2020 18:58:37 +0000

This article was originally published on the InnoGames Techblog and can be found here.

Introduction

Automated tests play a very important role in our games. In our daily business we add new game features, improve existing ones or do refactoring based on technical debt. Every single change could lead to a bug that breaks our game. Even simple changes like updating a version of an external dependency could lead to unexpected behaviour. Our tests ensure that the games are always in a stable condition and that the quality meets our expectations.

There are several types of automated tests that we use in our games. In this article I will focus on Backend System Integration Tests. In these tests, we test the entire game backend as a whole, including a real database. Usually they consist of three stages:

Preparation: Prepare a scenario in which we want to run the test action. This means setting up a test player with all conditions and requirements needed for the test action.
Execution: Run the action that we want to test. In most cases we call an API endpoint here.
Assertion: Validate that the outcome is the one that we expect.

Unlike in end-to-end tests, in which the preparation stage also uses API endpoints, the System Integration Tests directly manipulate the database. This has the advantage that it’s more flexible and leads to faster test executions. The drawback is that you have to basically mirror the business logic in your tests.

One problem we always faced was that the preparation stage could already make the tests unreadable, even in very simple test scenarios. Let’s take a city builder game as example. We want to write a test where we collect a finished production from a building that produces coins.

The preparation stage contains several steps:

Create a new player
Create a city for this player (imagine we can have multiple cities per player)
Place a building into the city that can produce coins
Create a production that is finished and can be collected
Set the initial coin amount of the player to do proper validation

Think a moment how you would write this test. A common way to go would be to create reusable test helper classes that we can use for the preparation steps. In the best case we have one line per step. It could look like this:

@Test
public void testCollectProduction() {
    var player = playerTestHelper.createPlayer();
    var city = cityTestHelper.createMainCity(player);
    var building = buildingTestHelper.createBuilding(city, "SomeProductionBuilding");
    productionTestHelper.createFinishedProduction(building, ResourceConstants.COINS, 20);
    resourceTestHelper.setAmount(player, ResourceConstants.COINS, 100);

    // call collect production endpoint

    // assert that I have 120 coins
}

But based on our experience it’s not always that easy. At some point you need to be more flexible. Either you end up with more parameters in a helper method or you have to create more and more helper methods to keep the test readable. It can happen really fast that the preparation code is bigger than the rest of the test. Looking at this test in a month, you need some moments to understand what happens.

Making the test setup readable

I would like to immediately understand what a test is doing, even when I come back to it after a year. To accomplish that, we introduced a builder-like API that allows us to define the whole test scenario by just configuring a scenario object:

@Test
public void testCollectProduction() {
    buildScenario(scenario -> scenario
        .withPlayer(player -> player
            .withResource(ResourceConstants.COINS, 100)
            .withCity("MainCity", city -> city
                .withBuilding("SomeProductionBuilding", building -> building
                    .withProduction(production -> production
                        .withResource(ResourceConstants.COINS)
                        .withAmount(20)
                        .withFinishNow()
                    )
                )
            )
        )
    );

    // call collect production endpoint

    // assert that I have 120 coins
}

As you can see, the test setup is much easier to read. The indentation makes it clear which configuration belongs to which entity and which entity belongs to which parent entity. The builder-like approach along with autocompletion makes it also fun to write such tests. We don’t have to think about test helper classes that need to be injected and if there’s a method that provides the functionality I need. We simply have to configure the scenario object by using the provided with-methods. The actual creation of entities happens in the background in the buildScenario() method.

But where do we get the generated IDs from? We created a building entity in the background, but we need to know the generated ID for the “collect production” action. For this case we can make use of reference objects:

@Test
public void testCollectProduction() {
    // create a reference object
    var buildingRef = new AtomicReference<Building>();

    buildScenario(scenario -> scenario
        .withPlayer(player -> player
            .withResource(ResourceConstants.COINS, 100)
            .withCity("MainCity", city -> city
                .withBuilding("SomeProductionBuilding", building -> building
                    .entityRef(buildingRef) // <-- reference object should contain this building entity
                    .withProduction(production -> production
                        .withResource(ResourceConstants.COINS)
                        .withAmount(20)
                        .withFinishNow()
                    )
                )
            )
        )
    );

    // call collect production endpoint with buildingId: buildingRef.get().getId()

    // assert that I have 120 coins
}

For the reference, we can use any simple reference holder. Java already comes with an AtomicReference class that provides the functionality we need, so we’re using this one for convenience reasons. We just create a reference object before building the scenario (of course this object is empty at that point). When buildScenario() creates the entities, the reference objects are also filled with the created entities. That means after buildScenario() was called, we can access the entities via referenceObject.get().

That’s nice! But the full power of reference objects will be clear in the next example. Let’s say we have workers that we can send to buildings in order to boost it. How can we assign a building to a worker when the building is not yet created? Just use the reference object:

@Test
public void testCollectProduction() {
    // create a reference object
    var buildingRef = new AtomicReference<Building>();

    buildScenario(scenario -> scenario
        .withPlayer(player -> player
            .withResource(ResourceConstants.COINS, 100)
            .withCity("MainCity", city -> city
                .withBuilding("SomeProductionBuilding", building -> building
                    .entityRef(buildingRef)  // <-- reference will be filled with this building entity
                    .withProduction(production -> production
                        .withResource(ResourceConstants.COINS)
                        .withAmount(20)
                        .withFinishNow()
                    )
                )
                .withWorker(worker -> worker
                    .withAssignedBuilding(buildingRef)  // <-- use the referenced building here
                )
            )
        )
    );

    // ...
}

You can see that we used the same reference object in two places. In one place it will be filled with the entity and in another place we use the created entity. Of course you have to make sure that the building is created first before creating the workers. But in the test itself we don’t have to care about it.

The implementation

There are two main components. You already saw the scenario object in action. This and all its children are called Configuration classes (all of them having a “Given” prefix). In addition we have the Setup classes (With a “Setup” suffix) that take care of the actual entity creation.

Configuration classes

There should be a Configuration class per domain logic or entity that can exist as a test requirement. The root class is the GivenScenario class. An instance of this class, the scenario object, is created and can be configured by calling the buildScenario() method which you saw in the examples earlier.

In our case the GivenScenario object contains a list of GivenPlayer objects, a GivenPlayer contains the player resources and cities, and so on. This should reflect your business logic. So, if a building belongs to a city, the GivenCity object should contain GivenBuilding objects.

A Configuration class typically ...

contains “with”-methods in order to configure it. A with-method is a kind of setter method, but should
- always return its own instance in order to provide a fluent API
- accept a Consumer parameter in order to configure the child object
contains getter methods for all configurations which should be used by the Setup classes
contains a reference to the Entity that is created by the Setup class. We abstracted this part to a GivenEntity class that you can find in the following example.

public class GivenScenario {

    @Getter
    private final List<GivenPlayer> players = new ArrayList<>();

    public GivenScenario withPlayer(Consumer<GivenPlayer> playerConsumer) {
        GivenPlayer givenPlayer = new GivenPlayer();
        playerConsumer.accept(givenPlayer);
        players.add(givenPlayer);
        return this;
    }

}

public class GivenPlayer extends GivenEntity<GivenPlayer, Player> {

    @Getter
    private final Map<String, Long> resources = new HashMap<>();

    @Getter
    private final List<GivenCity> cities = new ArrayList<>();

    public GivenPlayer withResource(ResourceConstants resourceId, long amount) {
        resources.put(resourceId.getKey(), amount);
        return this;
    }

    public GivenPlayer withCity(String cityDefinitionId, Consumer<GivenCity> cityConsumer) {
        GivenCity givenCity = new GivenCity(cityDefinitionId);
        cityConsumer.accept(givenCity);
        cities.add(givenCity);
        return this;
    }

    public GivenPlayer withCity(String cityDefinitionId) {
        cities.add(new GivenCity(cityDefinitionId));
        return this;
    }

}

public abstract class GivenEntity<G, E> {

    private AtomicReference<E> entityReference = new AtomicReference<>();

    @SuppressWarnings("unchecked")
    public G entityRef(AtomicReference<E> ref) {
        if (entityReference.get() != null) {
            ref.set(entityReference.get());
        }
        entityReference = ref;
        return (G) this;
    }

    public E getEntity() {
        var entity = entityReference.get();
        if (entity == null) {
            throw new IllegalStateException("Entity not set");
        }
        return entity;
    }

    public void setEntity(E entity) {
        entityReference.set(entity);
    }

}

Setup classes

A Setup class is responsible for building a specific part of the test scenario. In most cases there is a Setup class per domain logic or entity.

For example the CitySetup class is responsible for creating all cities defined in the scenario. The BuildingSetup class creates the buildings and also takes care of starting its productions.

Here’s an example of the CitySetup class:

@Component
@Order(ScenarioSetupPartOrder.CITY)
@RequiredArgsConstructor
public class CitySetup implements ScenarioSetupPart {

    private final CityService cityService;
    private final CityInitService cityInitService;
    private final GameDesignService gameDesignService;

    @Override
    public void setUp(GivenScenario scenario) {
        scenario.getPlayers().forEach(givenPlayer -> givenPlayer
            .getCities().forEach(givenCity -> createCity(givenPlayer, givenCity)));
    }

    private void createCity(GivenPlayer givenPlayer, GivenCity givenCity) {
        Player player = givenPlayer.getEntity();
        CityDefinition cityDefinition = gameDesignService.get(CityDefinition.class, givenCity.getCityDefinitionId());

        City city = cityService.find(player.getId(), cityDefinition)
            .orElseGet(() -> cityInitService.startNewCity(player, cityDefinition, Instant.now()));

        givenCity.setEntity(city);
    }

}

public interface ScenarioSetupPart {

    void setUp(GivenScenario scenario);

}

public class ScenarioSetupPartOrder {

    public static final int PLAYER = 1;
    public static final int RESOURCE = 2;
    public static final int CITY = 3;
    public static final int EXPANSION = 4;
    public static final int BUILDING = 5;

}

While the setUp() method receives the complete scenario object, it should just pick the information it needs to create the entities. After an entity was created, it should be passed to the configuration object (e.g. givenCity.setEntity(city)) which then fills the reference object to make it accessible in following Setup classes and tests.

As some Setup classes are dependent on others, the order is important. For instance the CitySetup class accesses the Player Entity which was created by the PlayerSetup before. The order can be ensured by an Order-Annotation on each Setup class, as you can see in the example above. We also created a ScenarioSetupPartOrder class to easily maintain the order. The Order-Annotation is part of the Spring Framework. If you inject a list of dependencies (e.g. List<ScenarioSetupPart>) it makes sure that this list is sorted based on the defined order.

Putting it together

Now that we have the Configuration and Setup classes defined, we can look at the buildScenario() method that should be placed in the base test class:

protected void buildScenario(Consumer<GivenScenario> scenarioConsumer) {
    scenario = new GivenScenario();
    scenarioConsumer.accept(scenario);
    scenarioSetup.setUp(scenario);
}

It creates an object of GivenScenario each time it is called. The Consumer parameter allows the caller to configure the object. Afterwards the scenarioSetup.setUp() method is called which just delegates to the specific Setup classes in the correct order:

@Component
@RequiredArgsConstructor
public class ScenarioSetup {

    private final List<ScenarioSetupPart> setupParts;

    @Transactional
    public void setUp(GivenScenario scenario) {
        for (ScenarioSetupPart part : setupParts) {
            part.setUp(scenario);
        }
    }

}

That’s it! When we create a new feature, we just have to create a Configuration and the related Setup class. Afterwards it can be used in any test.

Conclusion

This test setup architecture improved the readability of our tests a lot. Writing new tests or extending scenarios is very easy and the general maintenance effort is lower. If we’re doing a small refactoring, it might be enough to just update the Setup class and leave the actual tests untouched.

However, one downside is that we always have to keep some things in mind when we create new Configuration and Setup classes. For example setting the reference entities or having the correct order of Setup classes. Because the setup happens in the background, the reason for a test failure may not always be obvious.

But if you think further, this system will open up new paths for us. The preparation step is just a matter of configuring an object now. The configuration does not only have to take place in the test. We also created an API endpoint for our Frontend automation tests and in-game cheats. They can now make use of the same system to set up a player without any additional effort. But this is something for the next blog post ;)

Builder-like object creation without a Builder

Christian Blos — Fri, 09 Oct 2020 22:42:19 +0000

Writing understandable code is one of the most important aspects, especially when working in a team. In this article, I want to show you a simple alternative to the Builder pattern that makes your code more readable.

(Code examples are written in Java, but the idea can be adopted in other languages as well)

The scenario

Imagine we are working on a game where a player can fight against enemies. The enemies are configured in a JSON file. A JSON parser parses the file and creates enemy objects out of it. Here's how the Enemy class looks like:

@NoArgsConstructor
@Getter
@Setter
class Enemy {
    private String name;
    private int health;
    private int exp;
    private BattleAttributes attributes;
    private List<Attack> attacks;
}

@NoArgsConstructor
@Getter
@Setter
class BattleAttributes {
    private int strength;
    private int defense;
}

@NoArgsConstructor
@Getter
@Setter
class Attack {
    private String name;
    private int strength;
}

(The empty constructor and setters are a requirement of the JSON parser in this example)

Having all enemies configured as JSON, we don't need to create these objects manually in the game code, because the JSON parser does it for us. But we also want to write unit tests for our game. There we have to create Enemy objects by hand to provide mock data for our tests.

Creating the objects

Here's an example how we could create an Enemy object in our test:

BattleAttributes attributes = new BattleAttributes();
attributes.setStrength(5);
attributes.setDefense(4);

Attack bite = new Attack();
bite.setName("Bite");
bite.setStrength(1);

Attack slash = new Attack();
slash.setName("Slash");
slash.setStrength(4);

Enemy enemy = new Enemy();
enemy.setName("Some Monster");
enemy.setHealth(100);
enemy.setExp(5);
enemy.setAttributes(attributes);
enemy.setAttacks(List.of(bite, slash));

Since the Enemy depends on BattleAttributes and Attack objects, we have to create these objects first. But this makes the code less readable in my opinion. When we read the code from top to bottom, we don't see at first glance which object we want to create at the end. And sometimes we have to look twice to see which object is being used at which point. It might take a while until you really understand what we are doing here.

This problem can be solved by using the Builder pattern:

Enemy enemy = Enemy.builder()
    .name("Some Monster")
    .health(100)
    .exp(5)
    .attributes(BattleAttributes.builder()
        .strength(5)
        .defense(4)
        .build())
    .attacks(List.of(
        Attack.builder()
            .name("Bite")
            .strength(1)
            .build(),
        Attack.builder()
            .name("Slash")
            .strength(4)
            .build()
    ))
    .build();

Now when we read the code from top to bottom, we immediately see that an Enemy object is being created. The BattleAttributes and Attack objects are created at the point where we need them. This makes the code easier to understand.

However, there are cases when a Builder is not possible or not desirable. One argument against a Builder in this case is that we don't want to implement things in our actual game code just for testing.

So, how can we improve the readability of the object creation without a Builder? The answer is a simple helper method:

public static <T> T build(T obj, Consumer<T> consumer) {
    consumer.accept(obj);
    return obj;
}

This build() method can be implemented either in the base test class or in a separate helper class. It accepts any kind of object as the first argument and passes it to the Consumer that is given as the second argument. In the Consumer we can then configure this object (A Consumer is just a function with one argument and no return value). Finally the build method returns the object. Let's see it in action:

Enemy enemy = new Enemy();
enemy.setName("Some Monster");
enemy.setHealth(100);
enemy.setExp(5);
enemy.setAttributes(build(new BattleAttributes(), attributes -> {
    attributes.setStrength(5);
    attributes.setDefense(4);
}));
enemy.setAttacks(List.of(
    build(new Attack(), attack -> {
        attack.setName("Bite");
        attack.setStrength(1);
    }),
    build(new Attack(), attack -> {
        attack.setName("Slash");
        attack.setStrength(4);
    })
));

Final words

With a simple build() method you can create objects in a builder-like fashion without creating a Builder class. Since a Builder is not always possible, this approach could be a good alternative to make your code more readable.