Forem: Kenu Olotu

Unit Testing with FluentAssertions: Making .NET Tests Readable for Humans

Kenu Olotu — Wed, 18 Feb 2026 12:54:20 +0000

When I first started my internship, unit testing felt like a chore. In my head, I just wanted to build features and see them live on the new brand site I was developing. I’d write basic Assert.AreEqual statements just to tick a box, but they felt robotic and, honestly, a bit clunky to work with.

Then I discovered FluentAssertions.

The "Ah-ha" moment for me was realizing that my tests didn't have to look like math equations. They could look like English sentences. Instead of struggling through a wall of messy code to figure out why a test failed, I could read a line like response.StatusCode.Should().Be(HttpStatusCode.OK) and immediately know the intent.

Why Organization is More Than Just "Looking Nice"

As a Computer Science student, you hear a lot about "Clean Code," but you don't really feel its importance until you're six months into an internship with a deadline looming. I realized that keeping my tests organized wasn't just about being "easier on the eye", it was about saving time.

When your test suite is organized, you don't fear it. You actually start to rely on it. During my work on the subsidiary brand's site, I caught several bugs in my C# logic that I would have completely missed if I were just manually testing the UI. There’s a specific kind of relief when you see a red light in your test runner and realize, "Wait, I didn't handle the empty string case," before that bug ever hits a real user's phone.

Writing Tests That Read Like a Story

I believe that code should be a story that explains what the software is supposed to do. Using FluentAssertions allowed me to write tests that even a non-technical manager could almost understand.

For example, when I was testing the login logic, my assertions looked like this:

response.Data.Should().NotBeNull();

response.Data.Token.Should().NotBeNullOrEmpty();

This isn't just "organized" code; it’s self-documenting code. If I leave the company and another intern takes over, they don't have to guess what I was trying to check. The test tells them exactly what the expectation was.

The Real Value of Quality

If you’re a developer working with .NET, don't settle for the bare minimum in your tests. Taking that extra step to use tools like FluentAssertions makes your workflow smoother and your codebase much more professional. It’s the difference between just "coding" and actually practicing software engineering.

Why MVC is Still a Cheat Code for Modernizing Corporate Brands

Kenu Olotu — Wed, 18 Feb 2026 12:19:46 +0000

When I was assigned to rebuild a website for a subsidiary brand during my internship, I was met with a total disaster. The old site was the definition of "clunky." It was non-responsive, cramped, and looked like it hadn't been touched since 2010. If you tried to open it on a phone, you were basically looking at a desktop site shrunk down until the links were too small to click, assuming the links weren't already broken.

The temptation for any CS student in 2026 is to reach for the flashiest, newest JavaScript framework to show off. But the company had a very specific goal: they needed the site to look great, they needed it to rank on Google (SEO), and they needed it done fast.

That’s why I stuck with ASP.NET MVC. Here is why it was the right move and why people who call it "outdated" are missing the point.

The SEO Battle

One thing companies care about more than "cool" tech is visibility. Because the brand wanted to appear on Google searches, MVC gave us a massive head start. Unlike some modern frameworks that load a blank page and then "hydrate" it with JavaScript, which can be a hit or miss for search engine crawlers, MVC renders everything on the server.

By the time the browser gets the code, the content is already there. For a subsidiary brand trying to establish a digital footprint, that speed and crawlability are worth more than any fancy frontend animations.

Mixing Tailwind and Bootstrap for Speed

I knew I had to move fast, so I didn't lock myself into just one CSS philosophy. I used Bootstrap for the heavy lifting, the grids, the navbars, and the "clunky-proof" components that ensure the site won't break on a tablet.

However, to make it look "modern" and not just like another generic template, I sprinkled in Tailwind CSS. Using Tailwind for specific utility tweaks (like custom spacing or unique hover states) allowed me to polish the UI without writing 500 lines of custom CSS. It was about being efficient, not being a purist. I fixed the "cramped" mobile feel by using Bootstrap’s responsive containers but refined the look with Tailwind's utility classes.

The "Intern" Win

The biggest moment for me was the demo. When I showed the new responsive design to the team, the feedback was immediate. They weren't asking about the backend logic or the routing; they were looking at how smooth it felt on their phones. They said it was "really good," which is high praise when you're replacing a site that had been a source of frustration for years.

By using MVC, I was able to deliver a site that was stable, fast to load, and easy for the next developer to maintain. I didn't have to spend weeks configuring a complex frontend build pipeline; I just focused on the Model-View-Controller flow and got the job done.

The Real Lesson

If you're a student or an intern, don't feel pressured to use the most "sophisticated" stack just to look smart. Sophistication is about solving the problem. Fixing broken links, making a site mobile-responsive, and ensuring it’s SEO-friendly is what the business actually pays for. ASP.NET MVC might not be the "newest" kid on the block, but in a professional environment where time is money, it’s still a beast.

HUGE lesson here. Especially for younger devs.

Kenu Olotu — Tue, 10 Feb 2026 13:35:46 +0000

How I Used RestSharp to Stop My Internship Project From Crashing

Kenu Olotu ・ Feb 10

#dotnet #testing #webdev #api

How I Used RestSharp to Stop My Internship Project From Crashing

Kenu Olotu — Tue, 10 Feb 2026 13:33:09 +0000

When I started my web development internship, I thought my biggest challenge would be making a subsidiary brand's website look "nice" with SCSS and Bootstrap. I was wrong. The real headache started when I had to connect that pretty frontend to the Spotify API for user login.

In school, they teach you the theory of APIs, but they don't really prepare you for the moment your code just stops working for no apparent reason. I realized quickly that if I didn't want the login page to crash the second a real user touched it, I needed a way to verify my logic without refreshing a browser a thousand times. That’s why I turned to automated testing with RestSharp and NUnit.

Starting Small with Mocks

I’m a firm believer in not breaking things on purpose. Instead of hitting Spotify's actual servers immediately and risking a rate limit or a lockout, I used a mock API called ReqRes. This allowed me to test my C# models and my RestSharp logic in a clean environment.

The goal was simple: make sure the login request sends the right data and receives a token. Here is the foundation I built using NUnit and FluentAssertions. I used FluentAssertions because "Assert.AreEqual" feels robotic, while "Should().Be()" actually feels like I’m talking to my code.

using NUnit.Framework;
using RestSharp;
using System.Net;
using FluentAssertions;

namespace ApiTests;

[TestFixture]
public class LoginApiTests
{
    private RestClient _client;
    private const string BaseUrl = "https://reqres.in";

    [SetUp]
    public void Setup()
    {
        var options = new RestClientOptions(BaseUrl)
        {
            MaxTimeout = 10000 
        };
        _client = new RestClient(options);
    }

    public class LoginRequest 
    {
        public string Email { get; set; }
        public string Password { get; set; }
    }

    public class LoginResponse 
    {
        public string Token { get; set; }
        public string Error { get; set; }
    }

    [Test]
    public async Task Login_WithValidCredentials_ShouldReturnToken()
    {
        var request = new RestRequest("/api/login", Method.Post);
        var loginData = new LoginRequest
        {
            Email = "eve.holt@reqres.in",
            Password = "cityslicka"
        };
        request.AddJsonBody(loginData);

        var response = await _client.ExecuteAsync<LoginResponse>(request);

        response.StatusCode.Should().Be(HttpStatusCode.OK);
        response.Data.Token.Should().NotBeNullOrEmpty();
    }
}

Transitioning to the Real World (The Spotify Break)

Everything worked perfectly with the mock API. I was feeling like a pro until I swapped the URL to Spotify. Suddenly, everything broke.

The main culprit was the Client Secret. In my mock tests, I didn't really have to worry about complex headers or Base64 encoding. But Spotify is strict. If your Client ID and Client Secret aren't handled perfectly in the authorization header, the API doesn't just give you a "wrong password" error; it gives you nothing or a cryptic 400 Bad Request.

I spent hours realizing that my code was technically "correct" but my configuration was missing that one specific security string. It taught me that in .NET development, the code is only half the battle; the configuration is the other half.

The Manual Refresh Honesty

I’m going to be honest here: while I was testing, I didn't build a fancy automated token rotator. When the Spotify token expired, I manually updated it in my test setup.

Some people might say you should automate everything from day one, but as a student doing an extra year and trying to get things done, I learned that sometimes you just need to get the logic verified first. The manual refresh kept me aware of exactly when and why the token was dying. If I ever saw a "BadRequest" or "Unauthorized" status in my NUnit console, my first thought wasn't "my code is trash," it was "check the token."

Why This Saved the Project

Because I had these tests running in the background, I could catch errors before they ever reached the UI. There were multiple times where a change in my .NET MVC controller would have crashed the entire login page for the brand.

Instead of a user seeing a "500 Internal Server Error" on the website, I saw a red light in my Test Explorer. I could fix the logic, re-run the test, and only push the code when I was 100% sure the API connection was stable.

My Advice to Other Students

If you’re working on a project that feels "outdated" or you're trying to add modern features to an old brand, don't just focus on the CSS. Spend a few days learning RestSharp and writing even just three or four basic tests.

If your code keeps giving you an error that doesn't make sense, stop looking at the UI. Look at your request headers and your Client Secrets. Most of the time, the code isn't "retarded," it's just missing one tiny detail that the API is screaming for.