Archive for October, 2011

The “check computer” light

Wednesday, October 26th, 2011

On my way to work this morning my car’s check engine light came on. This is not an uncommon event, my car eats batteries and when the battery starts to fail and the car has trouble starting the light will come on. A few days later it generally clears itself. The couple times that the light has not cleared itself I have actually had to take it in to have it looked at.

This morning when it came on I suggested to my carpool buddy that I wished a built in feature of cars was to tell me why the light came on. Seems ridiculous to make me take it to someone to tell me what’s wrong with my car. Imagine if we had to take our computers to someone any time there was an error message in /var/log/messages. What a pain.

Ha! Take that car analogies of computers! I just made a computer analogy of cars!

I know you can buy those readers that will tell you the error codes. Although, my car is a VW that takes a non-standard reader and is more expensive than the common ones. Ah, German engineering.

(For my non-linux cohorts, /var/log/messages is the system log in linux)

coverage.py

Tuesday, October 25th, 2011

I was working on updating some unit tests today at work and was wondering if there was a way to measure the unit test coverage on a set of code. A single google search returned the ability for you to tell the exact test coverage your unit tests achieve and the exact lines of code that are not included in your coverage.

Enter coverage.py: http://nedbatchelder.com/code/coverage/

I’m on fedora so $ yum install python-coverage installed it for me.
To get the details suggested above you need only run two commands.

~/git/audrey git:(oauth*)➤ coverage run audrey_start/test_audrey_startup.py
……………
Ran 15 tests in 2.601s

OK

The coverage run command executes your code just as if you had executed it without coverage.py, but has generated data about the code it’s executing as it’s running. You can see here I’ve executed this code’s unit test script. Next you display the report data:

~/git/audrey git:(oauth*)➤ coverage report audrey_start/*.py
Name                               Stmts   Miss  Cover
——————————————————
audrey_start/audrey_startup          472    270    43%
audrey_start/test_audrey_startup     217     19    91%
——————————————————
TOTAL                                689    289    58%

~/git/audrey git:(oauth*)➤ coverage report -m audrey_start/*.py
Name                               Stmts   Miss  Cover   Missing
—————————————————————-
audrey_start/audrey_startup          472    270    43%   126-132, 186-216, 237, 241-243, 247, 288, 352, 379, 382, 388, 414, 456, 544, 558-559, 585-601, 609, 630, 640, 654-689, 700-730, 739, 747, 774-794, 837-847, 854-857, 907-936, 955-957, 975-1125, 1139, 1151, 1190-1195, 1203-1229, 1264-1340, 1344
audrey_start/test_audrey_startup     217     19    91%   65, 130, 384, 420-428, 505-526
—————————————————————-
TOTAL                                689    289    58%

The coverage report command will give you the percentages missing for each script. The coverage report -m command will give you the exact lines missing from the unit test coverage. I checked a few of these lines that it reported, a quick check seems to indicate these are all actual lines of code that were not executed during the unit test run. Pretty useful data for measuring the effectiveness of your unit tests.

Hitler, abortion and the Gospel

Wednesday, October 5th, 2011

What do Hitler, abortion and the Gospel of Jesus Christ have in common?

http://www.180movie.com/

Good stuff. Be patient through the Hitler stuff, he ties it in well.