racing · software · open-source

#2021 Supercross Predictions

Published on December 28, 2020 · 790 words · about 3 min reading time

With 2020 coming to a close, the 2021 Monster Energy AMA Supercross season is right around the corner. The first round is scheduled to be held in Houston, Texas on January 16th. This gives us a couple of days to think about who will be coming out on top in both the 450, 250 East and 250 West classes. Actually, the 250 entry lists aren't public yet, so we can only try to predict the 250 field as a whole, not knowing who will line up on either the west or east rounds' gates. That sounds a bit too artificial, so let's focus on the 450 division.

#Measuring code coverage in crystal with kcov

Published on February 24, 2019 · 615 words · about 3 min reading time

Crystal, the programming language, does not yet provide a built in way of measuring the effectiveness of your test suite. So by running crystal spec you pretty much only have binary insight into the suite: it's passing or it's not. This lead me to build crytic in the first place. But while mutation coverage is a great tool to investigate the test suite, plain old code coverage is usually quicker to obtain and easier to glance at.

#Introducing crytic - mutation testing in crystal-lang

Published on October 20, 2018 · 608 words · about 3 min reading time

While trying to be as pedantic as possible about test automation with this very blog's source code, I had two todos: performance and mutation testing. Both of those I did not have a plan yet as to how to tackle them. However, I have previously dabbled in mutation testing with ruby's mutant gem, so I at least had an idea of what to get out of a mutation test suite. Some searching revealed to me that there was no mutation test library yet for crystal. And what does the software engineer do in that case? Write his/her own of course! So I hereby present to you:

#Quick test feedback with fswatch

Published on July 28, 2018 · 203 words · about 1 min reading time

Loads of tools exist for continuously monitoring files on your disk for changes and running the tests whenever a change happened. Some test runners do that by themselves, others don't and rely on additional tools. The crystal test runner doesn't provide such an option, so I looked for an alternative. The easiest I found was the following:

fswatch -or ./src ./spec | xargs -I{} crystal spec

fswatch is using the system's (e.g. macOS) filesystem events to get notified of changes in files. Combining this with a pipe to xargs is making for a super simple tool to execute crystal spec whenever I change either a test or a production code file. Now for the arguments used:

  • -r, -recursive to fswatch is recursing subdirectories such that e.g. ./src/foo/ is watched as well
  • -o, --one-per-batch to fswatch is batching the filesystem events, otherwise you will get two triggers of your command for a single save in vim
  • -I{} to xargs specifies that none of the inputs piped in by fswatch are taken into account, because we are not using the replacement character {} in the crystal spec part. As the test suite is fast enough, I just run it in its entirety all the time.