DEV Community


Lab 8: An automated process on my urlAutomationMachine. Just what we needed

hyperthd profile image Abdulbasid Guled ・4 min read

So this lab is actually a pun on my release 0.1. Okay, I see what you did there, David! :P

For this lab, we're to do 2 things:

  • Write some automated tests for our release 0.1
  • Setup Github Actions so that pull requests and pushes to our master branch are automated

I feel as though this lab was the most exciting one yet. I know it's weird saying this at the end of the semester, but this lab involved two huge tasks that are a mainstay in the open source community at this point in time.

Writing test cases are important, because we as developers need to make sure that our code works as intended. Now, this was actually made alot harder for me due to the fact that most of my code was actually not refactored. This was the result of me not doing a previous lab on time. As a result, this was the very first thing I did.

I added 2 new functions to my url machine class. One returns the status code of the network request, of which I had to update the class to include an instance variable to store that and update that value in my make_requests function, and a checkUrl function that checks the url against the regex and either returns the regex object with the url, or none.

New functions

The second thing I did was organized everything in my root folder to make sure that things were properly in place. I kept the url_checker file in the root folder since that's where the program is ran from, but I included a "src" folder to store the class itself. I also made a folder to store my unit tests, docs, and resource files that I used here.

Folder structure

Lastly, I refactored my processFile and processUrl functions to ensure that proper parameters were being passed. Prior to this, I wrote the two functions assuming that the user would enter in the right values needed. This was something that no developer should ever do. It looks like my function became alot more bloated, but these checks really made testing my functions alot easier since I knew the exact pathing that would occur depending on what parameter was passed.

Refactored Functions

With these refactoring done, I began to write my test cases on a separate branch. With the changes that I made, writing the test cases really became so much easier for myself. I made a pytest fixture so that I could use them to check the status codes. Now speaking of status codes, I did not mock the request as most students have done. I instead relied upon a status code check function, which would retrieve the status code. This allowed me to simply make the request, and assert whether the status code was what I anticipated.

Pytest also has this nice thing where I can intentionally raise an exception, in order to check that the correct parameters were being passed. I did this with no urls, and even an object, the wrong value type to be presented.

The end result was this:

Test case examples

Running the "pytest" command, everything worked like a charm. So I rebased, merged, then pushed the test cases to github.

Next was the Github Actions themselves. This was much simpler than I thought. Github is nice enough to have some default actions for pretty much every popular language, and this also includes python. I simply selected the python application actions and the rest were history. Now, it runs flake8, instead of pylint, which is what I used. But, the end result is still the same. I might change flake8 to pylint in the future, but for the purposes of this lab, I kept it. It added the .github folder as intended and thus this step was complete.

The last piece was to write a test case for someone else and have someone else write one for myself. Currently, my partner, Mo is finishing up that. He's been delayed for reasons that I will not disclose, but with that, that concludes the lab.

This lab was definitely something that I fell in love with doing. It was also alot of work. Writing the test cases was a work in progress as I had trouble figuring out why some of my tests failed when they weren't supposed to. In the end, getting them all to work was the best feeling I had during a time in which I was not at my best from an emotional point of view. The next lab is where we finally make an official release for our release 0.1. I have some stuff I want to do before I make a release but when I do, my work will be complete. Until then, stay tuned


Editor guide