Lab8 OSD

This week we were tasked to implement testing functionality within our link checker code. You can find mine here.

The testing framework that I chose was Unittest, it is the basic testing framework and is actually included inside of Python with newer versions. You can find the link to it here

The code coverage tool that I used is called coverage, which you can find here.

Both of these tools were very easy to implement inside my project, all I had to do was install them with pip and off I could go with coding. (I also had to put them inside my requirements.txt file so other programmers could download them easily)

This was a very educational lab for me because I wasn't writing my code with testing in mind, this gave me a lot of trouble since I had to refactor a lot of my code so I could easily access the functions that I needed to test. If I could go back and rewrite my code for the first time, I would for sure do it with testing in mind. (But sadly I didn't even know anything about testing when I first started my link-check program)

Unittest actually has a built in mock feature using the keywords @patch and mock. Basically using @patch makes it so that any request that would be sent out by your program doesn't actually get sent out anywhere and instead will get replaced by the values that you put in.
These two lines is how I approached networked mock tests.

@patch("link_check.requests.head")  # Mock 'requests' module 'head' method.
mock_head.return_value.status_code = 200

Something that came up when I was running my code coverage analysis that I had a big problem with was getting it to run down all the pathways since I used an argument library to choose which part of the code to run. If I had to go back and do it again I would probably choose a framework that I could easily change the arguments that I am running with my code so that I could test all pathways of my code, but in the end I reached a 74% code coverage when I ran it with my tests which I think it pretty good, but can for sure be improved.

The GitHub Actions CI Workflow was very easy and all I had to do was make sure that It ran this line when it built:

python3 unittest

This would test all the files within the repository that had the keyword test in them.

I partnered up with someone that wrote his project in Go, this was pretty interesting since I never programming in Go. Fourtentatly for me his documentation was very straight forward and to the point so I could get coding right away, looking at other tests that he wrote I was able to pick up the syntax that I needed to use to write my tests. Overall it was fairly easy to write tests for my partners code.

I will 100% keep in mind testing while I am writing functions now. Another great thing is the Github Actions Workflows, these are very cool and I am actually going to be implementing it in my own personal website, which you can find here This way, when I create a pull request to my repository I can have a hosted pull request on netlify or something that shows the changes that I made before I accept the pull request. Something like how our telescope pull requests work.