This post not only explains how I got started with Tunir but also how I got started with unittest. My first unittest cases started with fedora cloud images.
It was a nice evening before Diwali. Kushal told on #dgplug that he needed new volunteers for Fedora Cloud SIG. Though I was totally clueless about cloud but I showed interest to join in because I would be able to learn something new and exciting. Next day, I and Farhaan had discussion with Kushal and he showed us how to write Python 3 unittest for Fedora cloud images (including atomic images).
Let me tell you about Tunir first. Tunir is a simple continuous integration system that helps us run automated test for cloud images. I would want you to visit Life Of Tunir which amazingly explains why we need Tunir and how it works.
So the aim is to convert manual testing into automated testing. Kushal gave us some shell commands and we convert them into Python 3 unittests. I have currently worked on NonGatingtests for cloud images. And this way I learned how to write unittest. I can run test for qcow2 cloud base image and atomic image. I have the images in my local machine. I just have to start the local server and follow the required steps to test the images. Whenever I got stuck at any test case Kushal and Rtnpro helped me a lot, Thanks to them 🙂 .
Now I am learning about mock. If test resources are not available mock helps us to replace it creating mock object. I am waiting for Kushal to give me the next task where I have to use mock.
If you also want to join as a volunteer for fedora cloud testing visit Need help to test Fedora Cloud images and Tunirtests/wiki 🙂 .
My code runs. But I didn’t ever think to care about whether it is clean or not. You might be wondering that why suddenly I have decided to write on this topic. Let me explain you the story.
I was going through badges of fedora and logged in to my account. And when I tried to view my profile as RDF it raised an Internal Server error. So I pinged Pingou on #fedora-apps about the issue and he told that the issue has already been reported. Since it was an internal server error I decided to run tahrir from my local host to know the reason behind the error(Though Ralph Bean has already commented the traceback on the issue later). And I followed README of tahrir to install tahrir for development purpose. There also I found some bugs, thus I sent a PR which was later merged. While initializing tahrir
$ initialize_tahrir_db tahrir.ini
I started getting traceback from dependencies. There was around 15 dependencies which threw traceback and I was like tahrir would not be working on my local machine 😛 . I finally installed all the dependencies with
$ pip install
and ended up with running tahrir from my localhost:8000 . I decided to send a PR to tahrir to avoid traceback from dependencies. Thus I did
$ pip freeze > requirements.txt
and sent a PR and asked Pingou & Threebean to review it. Pingou told me that requirements.txt contains all the dependencies those were installed on my virtualenv during setting up tahrir. It is not like tahrir requires all the dependencies listed in the requirements.txt to be installed on your virtualenv rather it needs only few of them. Well it can be explained like this
” If tahrir requires dependency A and installing A requires dependency B , then you do not need to include B as requirement. It will be dragged automatically while installing the dependency what you actually depend on which is A” — Pingou
Awesome lesson learnt! Hence I only needed to add requests and set an upper bound to rdflib. Thus I closed my PR and sent another PR to fix traceback. Though we were still getting traceback from twisted. As discussed with Pingou and Threebean on irc we realized it was an moksha.wsgi issue which was later fixed by Threebean. And now we won’t be getting any traceback when hacking tahrir.
And I learned that we really don’t need to include unnecessary things in code that makes it look bad. Not only running our code successfully but we should also care about keeping it clean and good. Thanks to Pingou and Ralph Bean for giving me such a wonderful lesson. You people really made my day 🙂 . My day ended with earning a developer badge from fedora. Now I am trying to work on the issue and reading the codebase of rdflib. Because for the version of rdflib<4.x there was no internal server error. Only for rdflib>4.x there comes an internal server error. So there must be some change in rdflib source code which is raising the Assertion error in tahrir . Wish me good luck friends 😉
Anyway enough of talking. I should stop writing now 😛 See ya!