Python

Throughout the years I have seen a lot of people struggling with writing useful and readable test cases. And I have also seen a lot of existing test code that has more resemblance with a bowl of spaghetti than it helps ensuring software quality. While some say that writing tests at all is better than not having automated tests, well-structured test code is vital to achieving most of the benefits claimed by the TDD community. As structuring tests seems to be a real problem for many, this post collects some personal advices on how to create a clean test code base that helps beyond technically checking program correctness. Table of contentsThe benefits of well-structured testsTests are a means of communicationTests as a tool for debuggingPreconditions for good testsAbstractionDependency injectionGuidelines for writing test casesVerify one aspect per test caseUse test case names to express readable requirementsTest your business, not someone else’sClarify requirements with syntax and features, don’t dilute themWhat to test and what not to testHow to provide test doubles: stubs and mocksConclusionBibliography The benefits of well-structured testsWhy does the structure of test code actually matter? Why should one bother with achieving clean test cases if a convoluted test function in the end verifies the same aspects of the code? There are (at least) two good reasons that explain why investing work in the structure of test cases is important. Note: This blog post focuses on techniques regarding tests that are written in a typical general-purpose programming language with tools such as xUnit-like frameworks. This usually isn’t the case only for unit tests. Also higher levels in the testing pyramid are often realized this way and the general recommendations given here are also applicable on this level. I do not specifically address tests realized using other, more declarative formalisms such as BDD-style testing. Still, some things probably apply there as well. Tests are a means of communicationAlthough reliably verifying that code performs and continues to perform the intended function is probably the primary reason for writing automated tests, well-structured tests can serve more purposes for developers, most of them boiling down to communication. The disputable Uncle Bob Martin has coined a famous quote in this regard: Indeed, the ratio of time spent reading versus writing is well over 10:1. We are constantly reading old code as part of the effort to write new code. …​ so making it easy to read makes it easier to write. — [Martin2009] p. 14...

Since a few years I am maintaining autosuspend, a small daemon that automatically suspends a Linux system in case no activity is detected. With version 2.0 I have added support for scheduled wake ups based on configurable checks for pending activities. ...

Most of the time at work I am currently doing machine learning / data science using the Python ecosystem. My editor of choice for working in Python has become Neovim, which really works well for autocompletion and linting based on Neomake, UltiSnips, deoplete and deoplete-jedi. However, one thing I have been missing was a tight integration with the IPython / Jupyter Console REPL in order to quickly experiment with new code fragments in a fashion like SLIME for Emacs: simply select a few lines of code and send them to IPython using a command / binding. Finally, I have found something that works well, which I will explain here. ...

A few months ago I sold my existing basic Synology NAS and built my own one based on a power-efficient Intel CPU inside a mini ITX system with a usual Linux as the operating system. This provided me with a lot more flexibility and e.g. possibilities to encrypt my data properly. One thing I needed for this custom solution was a daemon to suspend the system in case of inactivity to further reduce the power consumption. I found a few existing scripts online, started using one of them, but soon had to modify it deeply until it was general enough to suit my needs. Today, I finally took the time to clean up the last issues in the code base and the autosuspend project is now available on Github. ...

I have been struggling how to plot the separating hyperplane of an SVM (a One-class SVM in my case) in a 3D space using matplotlib. There was no apparent way how to convert the decision function output into something that one of the 3D plotting functions could deal with. Fortunately I found a solution which I am going to share in case someone wants to do the same. ...

I have implemented a handler for the Python logging system called broadcast-logging which sends out the log messages via UDP broadcasts. This might be useful in case you want to sporadically listen to certain log messages, e.g. from a server, without setting up a special service for this purpose. Since broadcasts are sent via UDP and no explicit connections are set up, this might also be useful in case you want to debug TCP-connection-related issues while preventing artificial connections for the debugging session. ...

I am using matplotlib a lot for my data analysis tasks and most things work as I expect them to do. One thing that I was missing so far for interactive use was the ability to focus an individual subplot and temporarily let it fill the whole screen for deeper inspection of this plot. In case of multiple subplots, with the standard GUI elements you can zoom and move around inside each subplot (without changing their geometry), but not focus one of them individually. Therefore I came up with the following solution: ...

I am using password managers since a long time to maintain secure and individual password for different online services. One thing that always bothered me was the missing integration of these password managers with different applications. I started my journey with password managers using KeePassX but recently switched to pass (the standard unix password manager) due to the inherent command line nature and therefore much better integration and remote usage possibilities. Still, there was no easy way to integrate pass with Git (for those repositories where SSH key authentication is not possible) and until recently I still used kwallet as the backend for Git, with all the hassles of duplicated data. To improve on this situation I finally took some time and implemented an adapter between Git and pass: pass-git-helper. ...

Nice parsing differences between python versions: languitar@cinnabar:~$ python2 -c 'print("test", "42")' ('test', '42') languitar@cinnabar:~$ python3 -c 'print("test", "42")' test 42

I don’t know why, but setting up the build system for a new software project and maintaining it seems to be something people are always afraid of. I’ve often heard people say “Eclipse does the job. It’s just additional work.” This usually leads to confusion and a lot of bulk and weird solutions several days later when the project starts to evolve, ultimately with much more “additional work”. Also in existing software project I have seen so many weird constructs effectively breaking the intended usage patterns and solutions of tools like CMake or setuptools, ending up with good software that is a nightmare to build and port to different platforms without insider knowledge. ...