## 6 Small Unit Testing Tips

Choosing test values when writing unit tests is mostly guided by the need to cover all cases of the program logic. However, some values are better than others. Here are a few tips on how to pick values that make mistakes easy to spot and the tests easy to read. Plus a bonus tip on a quick way to double check your tests.

## Mathematical Modelling of Football

This fall I took the course Mathematical Modelling of Football from Uppsala University. It was taught by Professor David Sumpter, and I believe this is the first academic course of its kind. The main subjects covered are modelling and analysis of events (on the ball actions), movement and pitch control (tracking data), player evaluation, and match result simulations. There were also several guest lectures from (among others) William Spearman, lead data scientist at Liverpool FC, and Javier Fernández, head of sports analytics at FC Barcelona.

The tools used were Python (using Anaconda) with NumPy, Pandas and Matplotlib. The course was a lot of work, especially the assignments, but I really enjoyed it and learned a lot.

## Deployed To Production Is Not Enough

You have developed a new feature. The code has been reviewed, and all the tests pass. You have just deployed this new feature to production. So on to the next task, right? Wrong. Most of the time, you should check that the feature behaves as expected in production. For a simple feature it may be enough to just try it out. But many features are not easily testable. They may be just one part of a complex flow of actions. Or they deal with external data fed into the system.

In such cases, checking if the feature is working means looking at the logs. Yet another reason for checking the logs is that the feature may be working fine most of the time, but given unanticipated data, it fails. Usually when I deploy something new to production, I follow up by looking at the logs. Often I find surprising behavior or unexpected data.

## Good Logging

To check if a program is doing what it should, you can inspect the output from a given input. But as the system grows, you also need logging to help you understand what is happening. Good log messages are crucial when troubleshooting problems. However, many developers don’t log enough information in the right places.

## Working From Home – Cons and Pros

Because of the Corona pandemic, our whole company has now been working from home for 12 weeks. Before, we mostly worked in the office, although occasionally people would work from home, for example when waiting for a delivery. This abrupt switch has made for a great natural experiment on the differences between these two ways of working.

Many developers on both Twitter and Hacker News argue that remote work is the future, and that they want to keep working remotely even after the need for it because of Corona is gone. For me, it has worked quite well so far. However, I miss some things. Others were not quite what I expected.

## Artificial Intelligence – A Guide for Thinking Humans

I really enjoyed reading Artificial Intelligence – A Guide for Thinking Humans by Melanie Mitchell. The author is a professor of computer science and an artificial intelligence (AI) researcher. The book is her attempt at working out if the singularity is near (or at least likely), or if we still are far from creating any true intelligence. In the process, the reader gets an excellent overview of the state of the art in areas such as image recognition, game play, and natural language processing. Even though it is aimed at general readers, I found it to be very good in technical content.

## 20.5 Years of XP and Agile

In the fall of 1999 I got the biggest productivity boost of my entire career as a software developer. In the October issue of IEEE Computer magazine, there was an article by Kent Beck called “Embracing change with extreme programming”. In it, he outlined Extreme Programming (XP), which includes much of what we now refer to as agile development.

By then, I had been working as a software developer for seven years. The standard development methodology at that time was waterfall: document-heavy year-long projects, frozen requirements, change control boards, manual testing at the end of the project, and so on. Software development succeeded despite the methodology, not because of it. Reading the article was a real eye-opener. I felt it was describing how I naturally worked – in short cycles, with fast feedback, and frequent redesigns.

(And yes, I meant to write this last fall for the 20th anniversary, but I didn’t get around to it then. But hey, better late than never, even if the title has 20.5 in it now)

## Secure by Design

I really like Secure by Design. The key idea is that there is a big overlap between secure code and good software design. Code that is strict, clear and focused will be easier to reason about, and will have fewer bugs. This in turn makes it less vulnerable to attacks. This is easy to say, but Secure by Design is full of techniques for how to actually do this. Here are the ideas from the book that I liked the most.

## More Good Programming Quotes, Part 4

Here are more good programming quotes I have found since my last post.

### Microservices

“Microservices are just dynamic linking over HTTP”
via @mononcqc

“kubernetes – turning things off and on again, at scale”