Beyond coverage

It looks like there are a lot of opin­ions or as­sump­tions about unit tests and ­code cov­er­age, most of them con­fus­ing of bi­ased in sev­er­al ways. For ex­am­ple, I’ve heard or read things like “this is fine, it has X% cov­er­age”, or “check­ing ­for cov­er­age on pull re­quests does­n’t help”, or “drop­ping the cov­er­age lev­el is not an is­sue”, and many more of the like.

This ar­ti­cle aims to shed some light on the is­sue of unit test­ing with and code ­cov­er­age. Hope­ful­ly by the end of it, we’ll get an idea of which of the pre­vi­ous state­ments are right and which are wrong (spoil­er alert: they’re al­l wrong, but for dif­fer­ent rea­son­s).

Read more…

PyCon CZ - Day 1

The day start­ed at 9.00, and at first it was time of check­-in, etc. Af­ter that, I solved one rid­dle by ki­wi.­com, and earned a dis­count in flight­s, which was a nice way to start the con­fer­ence.

Then af­ter break­fast and some net­work­ing go­ing through the booths of the spon­sors, it was time for the first talk of the day: “When bugs bite - why ne­glect­ing edge cas­es can kill“.

It was a great talk, a case for soft­ware en­gi­neer­ing in gen­er­al (it’s not Python-speci­fic, which is what makes the top­ic more in­ter­est­ing). The best thing I liked about the talk was the re­mark­s, and the idea of shift­ing the ­mind­set when it comes to de­vel­op­men­t, so we should do some “neg­a­tive think­ing” in the form of what can go wrong with this? How can this fail?, and such. It’s im­por­tan­t, be­cause this is crit­i­cal in or­der to make ro­bust soft­ware. Most prob­lems I have seen on soft­ware bugs were re­lat­ed to some op­ti­mistic think­ing, and even worse, op­ti­mistic unit test­ing, in the way that de­vel­op­ers on­ly test ­for hap­py-­path sce­nar­ios, with­out think­ing all sort of things that can go wrong.

Af­ter­ward­s, was the time for the talk about par­al­lel pro­cess­ing (poor per­son­’s ­par­al­lel pro­cess­ing), which was fine. Then I spent some time tack­ling some of the chal­lenges spon­sors had avail­able, so I did some cod­ing and re­cap of the events so far.

Then I lis­tened to a talk about wolfcrypt which is a tool for cryp­to in Python. The talk in­tro­duced some cryp­to con­cepts (sym­met­ric cryp­to, pub­lic key, etc.), which was good. Most of the ques­tions re­volved around com­par­i­son with oth­er tools in python (de­fault li­braries, py­cryp­to, etc.).

Then it was time for lunch and do some more cod­ing, and the next talk I at­tend­ed to was called “should I mock or should I not?“, which I liked very ­much and gave some food for thought.

Then it came one more talk, af­ter which it was time for mine, so I pre­sent­ed clean code in Python. There were some in­ter­est­ing ques­tion­s, and the en­tire p­re­sen­ta­tion went rel­a­tive­ly quick­ly.

Once the talk ses­sions were over, there was one last track for light­ning talk­s, which are al­ways su­per en­ter­tain­ing.

Af­ter the fin­ish of the first day, I at­tend­ed the speak­er’s din­ner, which was a nice op­por­tu­ni­ty to net­work with the com­mu­ni­ty, which is al­ways great.

Look­ing for­ward to some more in­ter­est­ing talks to­mor­row, and to see the re­sult­s of the chal­lenges.

The __set_name__ method for descriptors

De­scrip­tors gen­er­al­ly have to in­ter­act with at­tributes of the man­aged ob­jec­t, and this is done by in­spect­ing __­dic­t__ on that ob­ject (or call­ing getat­tr/se­tat­tr, but the prob­lem is the same), and find­ing the key un­der­ the spe­cif­ic name.

For this rea­son, the de­scrip­tor will have to know the name of the key to look ­for, which is re­lat­ed to the name of the at­tribute is man­ag­ing.

On pre­vi­ous ver­sions of Python this had to be done ex­plic­it­ly. If we want­ed to ­work around it, there were some more ad­vanced ways to do so. Luck­i­ly, af­ter PEP-487 (added in Python 3.6), there are some en­hance­ments re­gard­ing class cre­ation, which al­so af­fect­s de­scrip­tors.

Let’s re­view the prob­lem, the pre­vi­ous ap­proach­es to tack­le it, and the mod­ern way of solv­ing it.

Read more…