My final week commences. I had spend a little too much time developing for the project, and now I needed to use the remaining time left to carry out an integral part of software development, i.e testing the CRS application.
Being Put To The Test
Dr Shawn told me to write a bash script that utilizes the cURL command to send sample JSON payloads to the application, one by one. Each payload are in a separate JSON file, and each of these files represents a test case. The tests should incorporate two kinds of testing, which is positive testing and negative testing. Positive testing involves testing the behavior of the application when given valid inputs, while negative testing tests the behavior of the application when given invalid inputs.
There are two things that each test cases should have. One is the expected outcome of the test case, whereby you make an assumption or have an expectation of how the application should handle that particular test case, and the other would be the actual outcome or the result of the test case. If the expected outcome meets the actual outcome, then that test case passes for the application. After going though each test cases, the script will send a GET request to the application’s TSV Exporter REST API endpoint to generate the final TSV file output. For the given set of test cases, they should always produce the same TSV file as its final output. This means that the application should behave consistently under these test cases and have no side effects. To verify the final TSV file, the script produces a TSV file to verify against when executed with a certain argument. Then, executing the script without that special argument produces a temporary TSV file to compare against the original TSV file. Verification is done by obtaining a checksum for the original TSV file and the temporary one, and if their checksums match, then the overall test passes. Checksums are normally used to verify the integrity of files, e.g: when you download a certain file from a server, you derive a checksum for that file and match against the given checksum, to ensure that nothing is missing from the download.
From my perspective, I think that testing software is much more difficult than developing software. This is because there are so many possible outcomes for the software, and testing could only hope to cover not all but most of them. That being said, the test cases must be good enough to actually be representative of a possible real-life scenario that the software would have to handle for. I had to take some time thinking when coming up with these test cases, but slowly, I was able to do so. In the end, I had created about 22 test cases, which is sufficient for now as Dr Shawn mentioned. For future versions, more test cases would be added as more features are also added to the server application. It could possibly go well over a 100 test cases, which is totally normal in the software development world.
Deployment At Last
Three days passed, then the fourth day came. I had finalized the functionality of the application, and did lots and lots of testing, so the time had come to deploy my server application. Yay! I made a final push to the remote git repository and pull from it into the actual web server where my application would run. I rebuild the application to incorporate the latest changes then leave the application running in the server. I had never felt so relief in my life at that moment. I happily decided to just make one small order in the actual WooCommerce store just for the heck of it. Create the order, make the payment, then mark it as completed, everything should be fine right? Well, no. Looking into the CRS application logs, the application logger was complaining that the order was not in processing status when it was marked completed. Even more strangely, looking into the webhook delivery logs from the WordPress dashboard, it appears that the order was in pending status and then it jumped straight into completed status without going through the processing status. This comes to show that the webhooks could sometimes not behave the way it should, and also the CRS application should have send us an alert when such anomaly is detected, instead of just logging it. That is a minor bug of the application, and that should be fixed for the next version release of the application. The CRS application now rests in the hands of the next intern that would continue improving this project.
Anyhow, this marks the end of my somewhat short internship journey in AESTE. But just within these 2 and a half months, I had already learned so much about the real life process of developing software and also about myself as an aspiring software developer. Dr Shawn gave me a final talk about my problems and how I can improve from now on and he gave really good advice. The most important thing he told me is that the only way I could improve is through experience, but experience is not measured by time, rather by what you do. So I should continue to explore and create more things from various fields and find the one that piques my interests the most. I really needed to hear that.
I like to thank Dr Shawn for giving me this amazing opportunity and also to the other peeps in AESTE for making my internship a memorable one. I also would like to wish good luck to Nadia and the new intern, David, and hope that they do well for the rest of their internships. Til next time then!
0 Comments