How I Used RestSharp to Stop My Internship Project From Crashing

​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 = "[e-mail]",
            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.