Introduction
In unit testing with XUnit, we often use object arrays for test data. However, managing complex test data can quickly become cumbersome and hard to read. In this post, we’ll explore how to write cleaner and more scalable XUnit tests using TheoryData<T> without relying on object[] arrays.
Example Scenario: Retrieving Food by Type
Let's implement a FoodService class with a method that retrieves food items by type.
public enum FoodType { Fruit, Fast }
public interface IFoodService
{
public IEnumerable<string> GetByType(FoodType type);
}
public class FoodService : IFoodService
{
public IEnumerable<string> GetByType(FoodType type) => type switch
{
FoodType.Fruit => ["Apple", "Banana"],
FoodType.Fast => ["Pizza", "Burger"],
_ => throw new NotImplementedException()
};
}
Here, we use TheoryData<T> to hold our test cases, defining a FoodTestData record that includes input parameters, expected results, and a custom name for each test case:
public class FoodTests
{
// override ToString method allow us to specify name for individual tests in TheoryData<T>
public record FoodTestData(FoodType Type, IEnumerable<string> Expected, string TestName)
{
public override string ToString() => TestName;
}
// this method has the input parameters and expected values. we can scale this method with more tests without changes the test itself.
public static TheoryData<FoodTestData> GetFoodTestData() => [
new(Type: FoodType.Fruit, Expected: ["Apple","Banana"], TestName: "Test should return expected fruits"),
new(Type: FoodType.Fast, Expected: ["Pizza","Burger"], TestName: "Test should return expected fast food")
];
[Theory]
[MemberData(nameof(GetFoodTestData))]
public void ShouldReturnExpectedFood(FoodTestData foodTestData)
{
// Arrange
var mockFoodService = new Mock<IFoodService>();
mockFoodService
.Setup(x => x.GetByType(FoodType.Fruit))
.Returns(["Apple", "Banana"]);
// Act
var food = new FoodService().GetByType(foodTestData.Type);
// Assert
Assert.Equal(foodTestData.Expected, food);
}
}
Output
Conclusion
Using TheoryData<T> with a named record keeps our tests clean, easy to read, and scalable for future test cases.
Thank you for reading.
Top comments (0)