Good and Bad Tests

16. January, 2017

How do you distinguish good from bad tests in your code?

Check these criteria. Good tests

  • Nail down expectations
  • Monitor assumptions
  • Help to locate the cause of a failure
  • Document usage patterns
  • Allow to change code
  • Allow to verify changes
  • Are short (LOC + time)

Bad tests

  • Waste development time
  • Execute many, many lines of code
  • Prevent code changes
  • Need more time to write than the code they test
  • Need a lot of code to set up
  • Take ages to execute
  • Are hard to run


There are a lot of checks in your compiler. Those help to catch mistakes you make. Do the same with your tests. There are a lot of things that compilers don’t check: File encodings, existence of files, existence of config options, types of config options.

Use tests to nail down your expectations. Read config files and validate the odd option.

Create a test which collects the whole configuration of your program and checks it against a known state. Check that each config option is set only once (or at least that it has the same value in all places).

When you need to translate your texts, add tests which make sure that you have all the texts that you need, that texts are unique, etc.


Convention over configuration only works when everyone agrees what the convention is. Conventions are assumptions. Your brain has to know them since they are no longer in the code. If this approach fails for you, write a test that validates your assumptions.

Check that code throws the exceptions that you expect.

If you have found a bug in a framework and added a workaround, add a test which fails when the bug is fixed. Add a comment “If this test fails, you can remove the workaround.”


The world speeds up. No one can afford slow tests, tests that are hard to understand, hard to maintain, tests that get in the way of Get-Things-Done™. Make sure you can run your tests at the touch of a button. Make sure they never fail unless they should. Make sure they fail when they should. Make sure they are small (= execute fast, few lines to understand, little code to write, easy to change, cheap to delete). Ten tests, each asserting a single fact, are better than one test that asserts ten facts. If your tests run for more than ten seconds, you lose.


There is code rot. But long before that, there is documentation rot. Who has time to update the comments and documentation after a code change?

Why not document code usage in tests? Tests tell you the Truth™. Why give someone 100 pages of words they can’t trust when you can give them 100 unit tests they can execute?


Make your life easier. Stop wasting time in your debugger, begging for production log files, running code in your head. Write a good test today, it will watch your back for as long as the project lives. Write a thousand good tests and they will be like an army of angels, warding you from suffering, every time you press that button.

Quality in Software

19. November, 2016

Every software developer has seen too much bad code. Which raises the question what good examples are there?

Python, for one. Coverity, which scans software for all kinds of flaws, ranks the quality of Python among the best. Just 0.005 defects per 1,000 lines of code (the average being between 15/kloc and 50/kloc).

Risks of Artificial Intelligence

10. November, 2016

There is a growing group of people arguing how AIs will one day kill us, either by loving or hating us to death. I find their arguments interesting but lacking an important factor: AI is created by (a few) humans.

That means AIs will inherit features from their creators:

  1. Humans make mistakes, so parts of the AI won’t do what they should.
  2. Each human defines “good” in a different way at a different time.
  3. The road to hell is paved with good intentions.

My addition to the discussion is thus: Even if we do everything “as right as possible”, the result will still be “surprising.”


Mistakes happen at all levels of software development. They can be made during the requirements phase, when the goals are set. Requirements often are vague, incomplete, missing or outright wrong.

Software developers then make mistakes, too. They misunderstand the requirements, they struggle with the programming language, their brain simply isn’t at the top of its abilities 100% of the time.

When it comes to AI, the picture gets even more muddled. Nobody knows what “AI” really is. If two people work on the same “AI” problem, their starting set of assumptions is very different.

In many cases, we use neural networks. Nobody really understands neural networks which is the key factor: They “learn” by themselves, even if we don’t know what exactly. So they come up with “solutions” without a lot of effort on the human side which is great. It “just works”. Many such projects failed because the neural networks tracks a spurious correlation – something that happens to us humans every day.


What is “good“? Is it good when you add a feature to the software? When you’re really uneasy about it? When it’s immoral? Illegal? If it means keeping your job?

Is the success of a project good? What is “success”? It’s completed within time? Within budge? It’s somewhat completed at all? When the result is a rogue AI because too many corners were cut?

Unintentional Side Effects

The book “Avogadro Corp” tells the story of an AI which is created on purpose. The creator failed to take into account that he’s not alone. Soon, the AI acquired resources which it was never meant to have. People are killed, wars are prevented. Is that “success”?

Many people believe that strong leaders are “good” even when all the evidence says otherwise. They translate an insecurity into a wishful fact. If the wish of these people – often the majority – is granted, is that “good?” Is it good to allow a person to reject medicine which would save them because of personal belief? When all evidence suggests that the belief is wrong? Is it good to force happiness on people?

We want AIs to have an impact on the real world – avoid collisions with other people and cars, select the best medicine, make people spend more money on things they “need”, detect “abnormal” behavior of individuals in groups, kill enemies efficiently. Some of those goals are only “good” for a very small group of people. For me, that sounds like the first AIs won’t be created to serve humanity. The incentive just isn’t there.


AIs are built by flawed humans; humans who can’t even agree on a term like “good”. I feel that a lot of people trust AIs and computers because they are based on “math” and math is always perfect, right? Well, no, it’s not. In addition, the perceived perfection of math is diluted by greed, stupidity, lack of sleep and all the other human factors.

To make things worse, AIs are created to solve problems beyond the capability of humans. We use technologies to build them which we cannot understand. The goals to build AIs are driven by greed, fear, stupidity and hubris.

Looking back at history, my prediction is that the first AIs will probably be victim of the greatest mental human power: ignorance.

When Uncle Doc Gets Hacked

6. August, 2016

Most of the time, when users get infected with a computer virus or a Trojan, it’s a nuisance. But what happens when an important person becomes a victim of a cracker like your doctor?

How about this story:

I got a mail from a good friend. It had no text, just a link. I clicked the link and a web site of a big pharmaceutical company. It was a bit odd but I thought nothing of it. I’m a doctor, so I visit a lot of medical websites.

A couple of days after that, I got mails from old friends that thanked me for getting in touch with them again after such a long time. I was puzzled.

Yesterday, I got an email from myself. That I never wrote. It seems when I clicked the link above in my web mail, “something” happened.

Apparently, everyone in my address book got spammed.

The attackers got the address book. Which is inside the mail software. Which means they had access to the mail software. Which means they had access to all the mails. Do you exchange mails with your doctor? How much do you like the idea that “someone” out there had access to those mails?

We need to fix computer security.

Technical Solutions to Amok Runs

3. August, 2016

Every now and then, an idiot realizes that his life isn’t exciting enough and decides to do something about it. Note: I apply humor to horror.

Some people (I think of them as idiots as well, just a different flavor) think that arming everyone is the best solution to this problem. Maybe these people probably never get angry.

Anyway. Here is my attempt at a solution: Data contracts.

A data contract is a contract which is attached to data.

Example: I could attach a contract to data which my cell phone produces, for example, “code looking for the signature of gunshots can access data which the microphone produces.” Similarly, I could attach “code looking symptoms of mass panic can access data from my mobile’s acceleration sensors.” And lastly, “code which detected mass panic or gunshots is allowed to access location data on my mobile.”

To build such a system, all data needs to be signed (so it can be attributed to someone) and it needs to contain the hash code of the contract. Big data services can then look up people by their signature (which would also allow to create a public / shared signature for an anonymous entity) and from there, get the data contracts.

Now that in itself doesn’t protect against abuse of data by greedy / evil corporations. The solution here is the same as in the “real” world: Auditing. People applying for access to this system need to undergo an audit where test data is fed into the system and auditors (which can be humans or bots or both) validate the operation. This results in a digital document signed by the auditors which will then allow them to access the data feeds.

This approach would then protect my privacy from people wanting my movement profiles to annoy me with adverts while safety services could still use the data to automatically detect disasters and dispatch help without me having to fumble for my phone while running for my life.

On the downside, attackers will start to shoot mobile phones.

If we look into the future, unstable people could be sentenced to share some of their data with automated systems which monitor their mental state – I’m positive that several companies are working on systems to determine the mental state of a person by looking at sensor data from their phones or fitness sensors as you read this. Of course, we’d need an improved justice system (our current one is too busy with things like patent lawsuits or copyright violations) with careful balance and checks to prevent another kind of idiot (the one which doesn’t believe in “everything has a cost”) to run amok with this (i.e. putting “unwanted” people into virtual jails).

There is a certain amount of “bad things happening” that we have to accept as inevitable. Everyone who disagrees is invited to move to North Korea where they have … ah … “solved” this already.

For everyone else, this idea has a few holes. It needs computer readable contracts, a way to negotiate contracts between computers (with and without human interaction), it needs technology for auditors where they can feed test data into complex systems and see where it goes.

I think the computer readable contracts will happen in the next few years; negotiating contracts and knowing what contracts you have is a big issue with companies. Their needs will drive this technology. Eventually, you’ll be able to set up a meeting with a lawyer who will configure a “contract matching app” your mobile. When some service wants your data, the app will automatically approve the parts of the contract which you already agree, and reject those which you’ll never accept. If the service still wants to do business with you, then you’ll get a short list of points which are undecided, yet. A few swipes later, you’ll be in business or you’ll know why not.

The test data problem can be implemented by adding new features to the big data processing frameworks. Many of these already have ways to describe data processing graphs which the framework will then turn into actual data processing. For documentation purposes, you can already examine those graphs. Adding signature tracking (when you already have to process the signatures anyway to read the data) isn’t a big deal. Auditing then means to check those signature tracks.

It’s not perfect but perfect doesn’t exist.

RPM build errors: No file attributes configured

25. July, 2016

The error comes from this lines in the RPM source code:

if (initAttrs(fc) < 1) {
rpmlog(RPMLOG_ERR, _("No file attributes configured\n"));
goto exit;

initAttrs() looks for “%{_fileattrsdir}/*.attr”

To solve this, install the package rpm-devel.

Another solution is to create a file “script.attr” in _fileattrsdir (default: /usr/lib/rpm/fileattrs/) with this content:

%__script_requires %{_rpmconfigdir}/script.req
%__script_magic ^.* script[, ].*$
%__script_flags exeonly

Real Life Adblocker

17. June, 2016

I’m one of those people who can’t tear their eyes from blinking, moving stuff. Web advertising is pure hell for me. Thank god for ad blockers.

But what about real life ads? Did you notice all those billboards popping up lately? They are everywhere. Recently, the learned to move.

Time to do something about it:

Thanks, guys!