| Line 19: | Line 19: | ||
==The course SBR600== | ==The course SBR600== | ||
What can I say about this course? I remember [https://scs.senecac.on.ca/staff/selmys-john John Selmys] once told me that SBR600 probably is the most difficult course in the whole CTY program. I have to agree with him. I want to add that it's probably the most difficult course to teach as well. There are so many different knowledge sets brewing in one big pot. We are learning two to three courses material in one course. First we learned packaging. Then we learned Python and git (at least most of us did). We learned something else at the last stage. | |||
Revision as of 02:06, 11 December 2010
The Project
My project is testing fedpkg library using nose unittest frameworks. The set up of SBR600 project is to do three step releases: 0.1, 0.2 and 0.3. The first release is really about to learn the necessary tools. In my project, the main focus is Python scripting language. The second release is to working towards the direction of the project. But the outcome doesn't have to be complete or even anything significant. The final release has to make some sense.
The fedpkg program
fedpkg is a component within Fedora Packager. It is a python library and cli front end for managing Fedora packages within Fedora's git system.
Release 0.1
The release 0.1 is a demonstration of how to use nose to test some python script. The script I wrote is to work with list object.
Release 0.2
The release 0.2 is testing some functions in fedpkg library. I used unittest framework. I wasn't, however, understand well on the unittest setup. So that release just shown some knowledge of fedpkg code and some knowledge of unittest functions.
Release 0.3
The release 0.3 is really testing some library functions in fedpkg program. I tested three more functions on top of my release 0.2. A big improvement is that I got the unittest functions into my test code. In my 0.2, I had a hard time to use assertion from unittest framework. The simple reason is this: in fedpkg, the function _run_command doesn't return anything. So I can't compare the result from the fedpkg function and from the local os. Finally, I figure out a solution. I create a bash script inside my test code, and run the bash script. I redirect the output of the bash script to a file. Now I can exact data from the output file and compare to the results from the fedpkg function.
- One function I tested is _find_branch. An easy assertion is the default branch master (assertEqual). Then I use a bash script change the branch name (git branch and git checkout commands). When I run _find_branch again, I asserted that the branch is not master anymore (assertNotEqual).
- Next function I tested is _hash_file. I use a bash script to calculate the hash of a file and output to a local file. I exacted hash to a variable. Then I run _hash_file on the same file using the same hash type. The two hash values should be equal (assertEqual, again).
- The third function I tested is _verify_file. The function will verity the hash value against a predetermined value. Return true is they are the same. I generate a hash for a file. Then use the hash and the file as arguments in _verify_file. Assertion should be true (assertTrue).
The course SBR600
What can I say about this course? I remember John Selmys once told me that SBR600 probably is the most difficult course in the whole CTY program. I have to agree with him. I want to add that it's probably the most difficult course to teach as well. There are so many different knowledge sets brewing in one big pot. We are learning two to three courses material in one course. First we learned packaging. Then we learned Python and git (at least most of us did). We learned something else at the last stage.