Unit Tests For Rivals Of Catan Cards

by SLV Team 37 views

Hey guys! Let's dive into creating unit tests for all the cards in the base set of Rivals of Catan. This is super important because it ensures that each card functions correctly and consistently within the game. We'll be covering all the card types you've listed, making sure their effects are properly tested. Let's get started! We'll begin by outlining a general approach to unit testing, then we will delve into each card individually. Remember, unit testing involves testing individual components (in this case, card effects) in isolation to verify their behavior. Our goal is to ensure the game mechanics work as designed. We are going to ensure that each card is working properly, and we will cover all the cases that can happen while the game is running.

Toll Bridge Unit Tests

Our first card is the Toll Bridge. This card gives the player 2 gold when the event Plentiful Harvest is triggered. So, the main unit test here will be to verify this effect. We'll set up a test environment where we simulate the event and check the player's gold. Here's how we'll approach the unit tests. First, we need a setup function that initializes the game state, then we will roll the event Plentiful Harvest and trigger the card effect, and finally, we will verify that the player has received 2 gold. We'll also consider edge cases. For instance, what happens if the player already has a lot of gold? Does the card still function correctly? Does it cause any overflow issues? Does this affect another game mechanics? Testing for these types of edge cases can help prevent unexpected problems in a complex game like Rivals of Catan. We could even create a test to verify that gold is correctly awarded if a player has multiple Toll Bridges, or if other cards could interact with the gold. The goal is to ensure that the card accurately delivers its intended effect, under all circumstances. Let's make sure that all of these tests can be completed without a hitch. The test can go from simple to more complicated, as long as it has a goal.

Toll Bridge Test Cases

  • Test Case 1: Plentiful Harvest triggers. The player receives 2 gold.
  • Test Case 2: Player already has a lot of gold. The player receives 2 gold (no overflow).
  • Test Case 3: Multiple Toll Bridges. The player receives the correct amount of gold (e.g., 4 gold for two bridges).

Storehouse Unit Tests

Next up, we have the Storehouse! This card prevents the resources in the two neighboring regions from being counted during a Brigand Attack. This is an important card for players in the game. Our unit tests will focus on checking whether the storehouse correctly mitigates the impact of the Brigand Attack. We'll create a test scenario with a brigand attack and check the resource counts to ensure the storehouse's protection is effective. This means that we'll make sure that the storehouse properly reduces the amount of resources that a player loses. We'll make sure that the player's resources are not impacted, if the storehouse is in place, and that the resources are not impacted by any other effects. These tests can reveal how resources are handled with and without the storehouse active. We will need to set up the game state. We will simulate the scenario and check the resource counts of the player. This includes verifying the Storehouse functions as intended. The game engine is going to be tested, to make sure that the cards work as intended.

Storehouse Test Cases

  • Test Case 1: Brigand Attack triggered. Storehouse in place. Resources in neighboring regions are not affected.
  • Test Case 2: Brigand Attack triggered. No Storehouse. Resources in neighboring regions are affected.
  • Test Case 3: Storehouse placed between other buildings, to make sure that they are not affected.

Iron Foundry, Grain Mill, Lumber Camp, Brick Factory, Weaver's Shop Unit Tests

Okay, guys, let's group these cards together: Iron Foundry, Grain Mill, Lumber Camp, Brick Factory, and Weaver's Shop. These cards all share a similar function – they double the production of a specific resource in the neighboring regions. This means our tests will have a similar structure for all of them. Each card's unit tests will verify that the production of the respective resource is indeed doubled when the card is placed next to a relevant region. The core concept behind these tests remains consistent: we focus on confirming the production output before and after the building is placed. It's crucial to confirm that the production values accurately reflect the doubled output.

We will check if the resources are doubled. To do this, we need to know what the initial production is and then we will have to test the after-effect. We will also test the edge cases to see if the doubling is working as expected. If the player has multiple buildings in adjacent areas, the production can get complicated. We must carefully verify that the doubling effect is applied correctly. These tests will prevent unexpected issues in the game. Let's make sure the resources are handled properly. We need to be able to know how resources are handled with and without these buildings active. These tests will make sure that the game mechanics work and that players can rely on the effects of their cards.

Building Specific Test Cases

  • General Test Case: Before card placement, verify the initial production of the resource. After placing the card next to the appropriate region, verify the production is doubled.
  • Edge Case: Test with multiple neighboring regions of the same type to ensure the doubling effect is applied correctly to all.

Abbey, Marketplace, Parish Hall Unit Tests

Let's get into the unit tests for Abbey, Marketplace, and Parish Hall. Each of these cards has unique effects, and they require individual unit tests to verify their functionality. The Abbey gives 1 Progress Point (PP). The Marketplace gives 1 Commerce Point (CP) if the production number appears more frequently on opponents' regions. The Parish Hall allows players to pay only 1 resource for choosing a card from the draw stack. Each card needs to be tested in isolation to ensure that the effect is handled as intended. To start with, we need to make sure that the correct points are awarded. The next thing that we want to do is to test with the resource exchange. After that, we want to know if the actions are working correctly. We also want to verify that the effects are correctly applied in various game situations, and we must test edge cases as well. For example, when there are multiple Marketplaces or Parish Halls. The cards also need to be tested for specific scenarios to confirm that the game mechanics work as designed. If we use edge cases, we can make sure that we're covering all possibilities. By testing each card thoroughly, we can minimize potential game-breaking issues.

Card Specific Test Cases

  • Abbey: Verify that the player receives 1 PP when the card is played.
  • Marketplace: Test if the player receives 1 CP if the production number is rolled that appears more frequently on your opponents regions than on yours.
  • Parish Hall: Verify that the player only pays 1 resource when choosing a card from the draw stack.

Large Trade Ship, Gold Ship, Ore Ship, Grain Ship, Lumber Ship, Brick Ship, Wool Ship Unit Tests

Next, we'll unit test the Large Trade Ship, Gold Ship, Ore Ship, Grain Ship, Lumber Ship, Brick Ship, and Wool Ship. All of these cards provide 1 Commerce Point (CP) and allow trading of resources. Specifically, you may trade 2 resources from the neighboring regions. The unit tests for these cards will focus on verifying these trading actions. For each card, we'll set up test scenarios where a player tries to trade resources using the ship. The first thing we need to test is the awarding of the CP. After that, we have to verify the trading actions. To do this, we'll confirm that the correct resources are exchanged according to the card's rules. Each card has slightly different rules, and each card must be tested accordingly. Also, the edge cases are very important because they can potentially cause issues in the game. Make sure that we include a variety of scenarios to make sure that they're working as intended. The game engine should be tested, to make sure that the cards work as intended.

Ship Specific Test Cases

  • General Test Case: Verify the player gets 1 CP when the card is played. Then, test the trading action, ensuring 2 resources are correctly exchanged for the specified trade.
  • Edge Case: Test if the trade is possible if the player has only 1 resource to trade.

Austin, Harald, Inga, Osmund, Candamir, Siglind Unit Tests

Here's where we cover the unit tests for the character cards: Austin, Harald, Inga, Osmund, Candamir, and Siglind. These cards grant varying amounts of Strength Points (SP) and Skill Points (FP). This calls for a different set of tests. The primary focus of these tests will be to verify that the correct number of SP and FP are awarded when the card is played. Each card gives a different value of the points, so each card requires a separate test. Our tests will involve checking that the player's SP and FP values are correctly updated after playing the card. We will need to set up the game state. We will simulate the scenario and check the points received by the player. We also need to test edge cases, and each card will be tested separately to ensure that its specific effects are correctly implemented. We will make sure that the game mechanics work, and players can rely on the effects of their cards.

Character Specific Test Cases

  • General Test Case: When the card is played, verify the player receives the correct amount of SP and FP. For example, for Austin: Verify that the player receives 1 SP and 2 FP.

Remaining Cards Unit Tests

Let's move on to the remaining cards: Brigitta, The Wise Woman, Relocation, Scout, Merchant Caravan, Goldsmith, Invention, Yule, Year of Plenty, Fraternal Feuds, Feud, Traveling Merchant, and Trade Ships Race. These cards each have unique effects, demanding tailored unit tests. We will make sure that the unit tests can run and ensure the integrity of the game. For each card, we'll define test cases that specifically target its unique function. We will need to test the effects of these cards by setting up the necessary game states and simulating scenarios where the cards are played. The tests should cover both regular scenarios and edge cases to ensure robustness. The edge cases are essential, and we will need to ensure that the game handles all the situations.

Remaining Cards Test Cases

  • Brigitta, The Wise Woman: Test that you can choose the result of the production dice roll.
  • Relocation: Test that you can change the position of two regions.
  • Scout: Test that you can choose 2 cards from the region card stack.
  • Merchant Caravan: Test that you can discard 2 resources and take any 2 resources.
  • Goldsmith: Test that you can discard 3 gold and take any 2 resources.
  • Invention: Test that each player gets a resource for each building with PP.
  • Yule: Test that the event card stack is reshuffled and draw an event card.
  • Year of Plenty: Test that each region gets 1 resource for each adjacent Storehouse and Abbey.
  • Fraternal Feuds: Test that the player with the strength advantage selects 2 cards from the opponents' hand.
  • Feud: Test that the player with the strength advantage selects 3 of the opponents buildings.
  • Traveling Merchant: Test that each player may take up to 2 resources, paying 1 gold per resource.
  • Trade Ships Race: Test the player with the most trade ships receives any 1 resource.

Conclusion

Creating these unit tests is a crucial step towards ensuring that Rivals of Catan is robust, reliable, and fun to play. By methodically testing each card and covering different scenarios and edge cases, we're building a foundation for a high-quality game experience. Remember, these tests can be adapted as the game evolves. So, keep them up-to-date. Happy testing, guys!