Writing automated tests is essential for building reliable and maintainable software…
But test data setup often becomes a bottleneck. Hardcoded values, duplicated fixtures, or overly simplistic data can lead to brittle tests, false positives, or unrealistic coverage.
That’s where fake data generation comes in.
By using realistic but controlled fake data, you can isolate behaviors, simulate edge cases, and improve confidence in your system, especially when working with complex models or integration layers.
Let’s fake smart and test better.
What is Bogus?
Bogus is a popular C# library for generating fake data. You define your model, tell Bogus what to fill, and it handles the rest.
Instead of passing hard-coded values to your tests:
var customer = new Customer
{
Id = 1,
FullName = "John Doe",
Email = "john.doe@example.com",
RegisteredAt = new DateTime(2022, 1, 1)
};
This works, but it doesn’t scale, every test ends up with the same data.
You’ll hit limitations quickly, especially with collections, edge cases, or database constraints.
Now here’s the same object using Bogus:
var customerFaker = new Faker<Customer>()
.RuleFor(c => c.Id, f => f.Random.Int(1, 1000))
.RuleFor(c => c.FullName, f => f.Name.FullName())
.RuleFor(c => c.Email, f => f.Internet.Email())
.RuleFor(c => c.RegisteredAt, f => f.Date.Past(3));
var customer = customerFaker.Generate();
This gives you:
Different values every time
More realistic data
No repetition across tests
A single source of truth for your test setup
You can even generate a list of fake customers with customerFaker.Generate(10).
In short: if you’re still copy-pasting dummy values into your tests, Bogus is the upgrade you need.
Bogus is trusted by developers and teams at:
- Microsoft – used in official .NET testing samples and internal tooling
- JetBrains – featured in ReSharper test examples and webinars
- Stack Overflow – leveraged in internal utilities and mock services
- ABP Framework – uses Bogus to seed modular app layers
- Fluent Validation – uses Bogus in unit tests and validator examples
Setting Up Bogus
Getting started with Bogus takes less than a minute.
Using the CLI:
dotnet add package Bogus
Or via the Package Manager:
Install-Package Bogus
That’s it… no extra dependencies or setup required.
Start with a simple model. For example:
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
}
Now use Faker<T> to define the rules:
var customerFaker = new Faker<Customer>("pt_BR") // Locale support
.RuleFor(c => c.Id, f => f.IndexFaker + 1)
.RuleFor(c => c.FullName, f => f.Name.FullName())
.RuleFor(c => c.Email, f => f.Internet.Email())
.RuleFor(c => c.City, f => f.Address.City());
var customer = customerFaker.Generate();
Notice the “pt_BR” locale. That’s how you get localized names, emails, addresses, etc.
For example, f.Name.FullName() will now return something like “Carlos Henrique” instead of “John Smith”.
Tip: Keep your fakers reusable.
Using Fake Data in Tests
Let’s say you have a service that calculates discounts based on a customer’s registration date.
Here’s how a test might look:
[Fact]
public void Should_Apply_Discount_For_Old_Customers()
{
var customerFaker = new Faker<Customer>()
.RuleFor(c => c.Id, f => f.IndexFaker + 1)
.RuleFor(c => c.FullName, f => f.Name.FullName())
.RuleFor(c => c.RegisteredAt, f => f.Date.Past(5)); // registered 5 years ago
var customer = customerFaker.Generate();
var result = _discountService.Calculate(customer);
Assert.True(result.HasDiscount);
}
Want to test recent customers? Change the rule:
.RuleFor(c => c.RegisteredAt, f => f.Date.Recent(30));
Bad faker design = flaky tests.
Good faker design = stable, realistic, maintainable suites.
The goal isn’t just fake data , it’s useful fake data that strengthens your tests, not weakens them.
Seeding Development Databases with Bogus
If you’re using EF Core, you can combine Bogus with a custom DbContext seeder. This gives your app enough realistic data to develop, test UIs, or debug business rules, without relying on production dumps or static JSON.
Here’s how to do it right:
var customerFaker = new Faker<Customer>("pt_BR")
.RuleFor(c => c.Id, f => 0) // Let EF Core handle IDs
.RuleFor(c => c.FullName, f => f.Name.FullName())
.RuleFor(c => c.Email, f => f.Internet.Email())
.RuleFor(c => c.RegisteredAt, f => f.Date.Past(3));
Seed the Database:
public static void Seed(AppDbContext context)
{
var customerFaker = new Faker<Customer>("pt_BR")
.RuleFor(c => c.Id, 0)
.RuleFor(c => c.FullName, f => f.Name.FullName())
.RuleFor(c => c.Email, f => f.Internet.Email())
.RuleFor(c => c.RegisteredAt, f => f.Date.Past(3));
var customers = customerFaker.Generate(50);
context.Customers.AddRange(customers);
context.SaveChanges();
}
Just like with tests, the quality of your seed data matters. Define realistic rules, use locales where needed.
Conclusion
Bogus is one of those libraries that saves you hours, if you use it right.
Whether you’re writing unit tests, seeding a local database, or mocking data for integration tests, realistic fake data makes your system more robust and your tests more meaningful.
Get started here: Bogus
Thank you for reading.
See you next time!
