Writing tests for Rust HTTP source | GSoC 2019

Writing test is an important part of Plugin development in GStreamer or rather for all most all software development. There are several reasons which clearly tells us as why writing test cases are important.

1. To point out the defects and errors that were made during the development phases
2. To check whether all features are working at every change
3. To figure out unhandled scenarios in our software

My GSoC mentor, Sebastian Dröge coded the skeleton of the test with a basic unit test case for HTTP source plugin (aka reqwesthttpsrc). Here is the link to the merge request. The test was to check whether we receive the data correctly which is sent by the server. Here we make a hyper HTTP server which respond with "Hello World". Then we use our plugin to receive the data and we compare both. Also the interesting thing here is the Custom test harness which can be used to initialize a HTTP server with required behavior and our HTTP element with required properties set. We can use this to create the desired Harness for the any test case.

After studying and going through the existing test cases, I started writing test case to check whether 'Server not found error' (404 error) is handled correctly. So I used the Custom test harness to create a HTTP server which returns 404 error and HTTP plugin with default settings. Then I set the plugin to PLAY and wait for an error. Using the assert_eq! macro I compare the results. Here is the gitlab link to the merge request.

Before going to the next test case let me give a brief on states. A state describes whether the element instance is initialized, whether it is ready to transfer data and whether it is currently handling data. There can be 4 states for a element they are NULL, READY, PAUSED and PLAYING. Please refer to this from documentation. 

Next test case has two parts. This test is basically about seeking and checking for data stream. Here I have made an HTTP server return a very large buffer, which I will receive asynchronously chunk by chunk. These are the scenarios

1. Seeking after the element reached READY state.
2. Seeking after a buffer was received already.

In the first case it's initially set it to READY and then I seek. After that I set the element to PLAY. Now I check the segment whether seek has properly happened and check the received buffer whether the data is correct. Here is the gitlab link.

Second scenario it's initially set to PLAY as usual and I wait for a buffer then I seek. Finally check like I've done in above case. Additionally I'll make sure there is no old buffer

arriving before the segment event.

Writing test was a great way for me to understand the flow, detail about the APIs and how data is handled. I learned a lot more during this period comparing to the previous weeks. More posts coming up, buckle up ;)