From Fedora Project Wiki

 
(13 intermediate revisions by the same user not shown)
Line 7: Line 7:


==Release 0.2==
==Release 0.2==
[http://matrix.senecac.on.ca/~zwang98/test_fedpkg.py 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==
==Release 0.3==
[http://matrix.senecac.on.ca/~zwang98/test2_fedpkg.py 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 extract 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 extracted 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==
==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.
I still believe a preparation for SBR600 will ease things up (say, call it SBR500). The preparation course has no project. But SBR600 is all project. The first 3 weeks are getting a overview of different projects. Then students can decide which project is suit their knowledge and interest.
Overall, I did benefit a great deal from this course. At the minimum, I learned Python scripting. I have to say that the level I learned Python here is more than bash scripting and C programming I learned from other courses.

Latest revision as of 02:51, 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 extract 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 extracted 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.

I still believe a preparation for SBR600 will ease things up (say, call it SBR500). The preparation course has no project. But SBR600 is all project. The first 3 weeks are getting a overview of different projects. Then students can decide which project is suit their knowledge and interest.

Overall, I did benefit a great deal from this course. At the minimum, I learned Python scripting. I have to say that the level I learned Python here is more than bash scripting and C programming I learned from other courses.