After the backend implementation of the first user story, I wanted to do an integration test. Based on the user story, I want to define test scenarios, and test cases. From there I want to decide if the user story is satisfied and potentially make improvements for the application. # The user story | ID | Definition | | --- | --- | | 1 | As a process owner, I want to be able to monitor the status of a project by seeing the status of the tickets. | For this user story, I implemented functionality that fetches and stores data. I'm going to compose some test cases to validate if this functionality works. # Test scenarios | ID | Testscenario | | --- | --- | | 1 | The application starts without the credentials that are needed to fetch data from the REST API. | | 2 | The application starts without the necessary filter ids. | | 3 | The application starts with all the configuration data. | # Test cases Next, I wanted to describe the testcases. The application needs some configuration values to function properly, and I want to test what would happen if the user doesn't provide these values. I also put down the excepted result. The application runs as a hosted service, but only makes reports at night. I want the application to communicate directly if all the needed configuration data is provided, and not in the middle of the night when a report should be generated. | ID | Testcase | Expected Result | | --- | --- | --- | | 1 | Start the application without the credential's configuration | The application should throw an exception immediately | | 2 | Start the application without the filter ids configuration | The application should throw an exception immediately | | 3 | Start the application with all the configuration values | The application should generate all the reports | # Test results The test cases were defined so I could execute the tests. First, I ensured that the application is working fine before doing any test. This way I can ensure that I'm testing the correct things. After I confirmed that the application was working as expected, I started my testcases. I started with `1`, so I removed the base address from the configuration values and as expected: ```plaintext Unhandled exception. Microsoft.Extensions.Options.OptionsValidationException: DataAnnotation validation failed for 'JamaCredentialsOptions' members: 'BaseAddress' with the error: 'The field BaseAddress must match the regular expression '^http.*'.'. ``` The application won't crash due to the fact it tries to **use** the `BaseAdress`, but it will crash Preemptively, because it will run `DataAnnotion` validation, giving use much more control and safety. So to be clear, the unhandled exception that is being thrown is the desired behavior. The type of the exception is `OptionsValidationException`, indicating that the program validates the configuration values, before using them. If this exception isn't thrown, the application will try to use `BaseAddress` as a regular URL, even if its emtpy. This would be undesirable. Before starting testing with `2`, I made sure that the app worked again after providing `BaseAddress` to establish a good baseline. I then removed the filterIds in the configuration and... tadaa!: ```plaintext Unhandled exception. System.IO.FileNotFoundException: The configuration file 'JamaFilterIds.json' was not found and is not optional. The expected physical path was 'C:\git\xxt\Tools\MetricsDashboard\server\src\ReportWorker\bin\Debug\net8.0\JamaFilterIds.json'. ``` Again, this assertion is done at startup and is not deferred to the moment the filter ids are needed, for extra safety. I put the filter ids back into the configuration, and tested `3`. This is where I stumbled on an error, and the expected test result was not met. I got the following error: ```plaintext fail: ReportGenerator.Clients.Jama.JamaClient[0] Request failed with status code TooManyRequests: 429 Too Many Requests

429 Too Many Requests

nginx/1.18.0 ``` The Jama server responded with a HTTP code of 429, which meant my application made to many requests. **Test Report** | ID | Pass/Fail status | Actual results | | --- | --- | --- | | 1 | Pass | The application threw an exception on startup indicating that configuratin was missing credentials section. | | 2 | Pass | The application threw an exception on startup indicating that configuration was missing filter ids section. | | 3 | Fail | The application had an ratelimit error. | # Request for improvement After my test failed, I wanted to do some debugging. I found a section that told me that I could only make 10 request per second in the Jama rest API [docs](https://support.jamasoftware.com/hc/en-us/articles/28404784298509-Sample-API-calls-to-Jama-Connect#:~:text=The%20Jama%20REST%20API%20employs,until%20the%20request%20load%20decreases.). So, I knew, I had to make a `throttled HTTP client`, that would only make 10 request per second. I made a ticket for this fix and got to work. ![Ratelimit handler ticket screenshot](https://api.daaneggen.nl/uploads/ratelimit_handler_ticket_56950ff088.png) # Implementation of improvement I created a class that implements `DelegatingHandler`. In this class you can define custom logic for your httpclient. In my implantation, I added a field wich holds a shared resource, a `semaphore`. This recourse has available slots (10 per second in this case). Every message that is send in the HTTP client, will need a slot, and if none is available, the client will wait. This way, I can respect the ratelimit. ```csharp namespace ReportGenerator.Clients; ///

/// A delegate handler that can be used to throttle HTTP client requests in order to proactively manage rate limits. ///

public class RateLimitHandler : DelegatingHandler { private readonly SemaphoreSlim _semaphore = new(10, 10); // 10 concurrent slots private static readonly TimeSpan Interval = TimeSpan.FromSeconds(1); /// protected override async Task SendAsync( HttpRequestMessage request, CancellationToken cancellationToken) { await _semaphore.WaitAsync(cancellationToken); try { return await base.SendAsync(request, cancellationToken); } finally { _ = Task.Delay(Interval, cancellationToken).ContinueWith(_ => _semaphore.Release(), TaskScheduler.Default); } } } ``` The last thing I have to do is registering this handler to the HTTP client while setting up the `DI container`. ```csharp builder.Services.AddHttpClient() .AddHttpMessageHandler(); ``` To validate my implementation, I executed the last testcase again. I saw the following in the logs. ```plaintext info: ReportWorker.ReportBackgroundWorker[0] Successfully generated and saved 139 reports ``` I didn't get any 429 errors, so I knew my fix worked. | ID | Pass/Fail status | Actual results | | --- | --- | --- | | 3 | Pass | The application generated all the reports |

<DaanEggen/>

</>

In this article

Testing & Improving the ReportWorker

In this article