Before we start writing our own LINQ methods, we’ll take a quick step back to prepare a strong foundation: unit testing.
In this article, we’ll use xUnit to define how our LINQ-like methods should behave before we even implement them.
This approach will make our next article — where we start coding Where and Any — much easier to understand and validate.
Why Write Tests First?
We’ve already learned about IEnumerable, extension methods, and yield return. Now it’s time to put that knowledge to work.
But instead of jumping directly into coding, we’ll describe how our methods are supposed to behave — using unit tests.
Writing tests first gives us:
- A clear definition of what each method should do.
- Confidence that our implementation works.
- Easier debugging later, since failing tests tell us exactly what’s wrong.
This is the spirit of Test-Driven Development (TDD) — write tests first, make them fail, then implement the logic until they pass.
Setting Up xUnit
We’ll use xUnit, a popular and lightweight testing framework for .NET.
To create a new test project, open the terminal and run:
dotnet new xunit -n MyLinq.Tests
Then, add the reference packages to the project:
cd MyLinq.Tests
dotnet add MyLinq.Tests.csproj package xunit
dotnet add MyLinq.Tests.csproj package xunit.runner.visualstudio
dotnet add MyLinq.Tests.csproj package Microsoft.NET.Test.Sdk
Now, we can start writing tests inside the MyLinq.Tests project.
Each test class should focus on a single area of your code, for example, we’ll start with Where and Any.
Writing Our First Test: Where
Let’s describe what we expect our future Where method to do:
public void WhereOfArrayOfNumbers()
{
var myListOfNumbers = new[] { 1, 2, 3, 4 ,5 , 6, 7, 8, 9 };
var myResultAfterFilter = myListOfNumbers.Where(i => i <= 5);
var myListOfExpectNumbers = new[] { 1, 2, 3, 4, 5 };
Assert.Equal(myListOfExpectNumbers, myResultAfterFilter);
}
We’re calling the method Where, which is a LINQ method, that in the future we are going to replace for our own.
Testing the Any Method
Now let’s define tests for another common LINQ method: Any.
[Fact]
public void AnyOfEmptyArray()
{
var myListOfNumbers = new int[] {};
var myResult = myListOfNumbers.Any();
Assert.False(myResult);
}
[Fact]
public void AnyOfArrayOfNumbers()
{
var myListOfNumbers = new[] { 1 };
var myResult = myListOfNumbers.Any();
Assert.True(myResult);
}
[Fact]
public void AnyOfArrayOfNumbersWithFilterLessThenFive()
{
var myListOfNumbers = new[] { 5, 6, 7 };
var myResult = myListOfNumbers.Any(i => i < 5);
Assert.False(myResult);
}
[Fact]
public void AnyOfArrayOfNumbersWithFilterMoreThenFive()
{
var myListOfNumbers = new[] { 5, 6, 7 };
var myResult = myListOfNumbers.Any(i => i > 5);
Assert.True(myResult);
}
These tests give us a clear idea of what we expect from the implementation we’ll build next.
What’s Next
In the next article, we’ll finally implement our own methods from scratch. The methods will have the same name as LINQ, and we are going to point the test to the new namespace (intead System.Linq).
By starting with tests first, we’re setting the stage for a more predictable and maintainable LINQ-like library.
Key Takeaways
- Write tests before implementation to define expected behavior.
- xUnit makes it easy to structure and automate C# tests.
- We’re now ready to implement our own LINQ methods!
✅ That’s all, folks!
💬 Let’s Connect
Have any questions, suggestions for improvement, or just want to share your thoughts?
Feel free to leave a comment here, or get in touch with me directly on LinkedIn — I’d love to connect!
Top comments (0)