Thomas Arts
Erlang developer since 1997, co-founder and CTO of Quviq
Thomas Arts co-founder and CTO of Quviq has an academic background with a PhD in theoretical computer science. Directly after his PhD, Thomas started at Ericsson's computer Science Lab on verification tools for Erlang. After a short return to academia as professor at Chalmers, he is now fully devoted to amazing testing tools.
Quviq is the company that productified QuickCheck, a tool that automatically generates tests. The tool is written in Erlang, but can be used to test systems written in a variety of languages. Among other successes, it is heavily used within the telecom and automotive industry, for example for testing 5G base stations and AUTOSAR standard software. Recently Quviq has put a lot of effort in the development and testing of blockchain implementations.
Past Activities
Code BEAM STO 2019
14.30 - 15.15
How to sleep well after a major code refactoring
We all change our mind and realise that our code needs a major refactoring in order to meet new ideas. In the Aeternity blockchain project this has happened several times. A block chain is very sensitive to changes, because blockchains elementary are based upon hashes of terms that should match with earlier hashes. A change that causes a hash to differ could mean that people can no longer access their assets on the blockchain.
OBJECTIVES
Explain how refactoring can be addressed without too much worrying.
AUDIENCE
Software engineers and managers that like a good night's sleep.
Code BEAM V Europe 2021
14.20 - 15.00
Fireside chat on bringing more FP to Elixir
In this fireside chat, Brooklyn and Thomas will talk about structural thinking and abstraction. Come hear (and discuss!) how to make your code more understandable, help you move quickly, and eliminate tricky bugs, drawing from real world examples, the Witchcraft suite, and Exceptional.
Code BEAM Lite Amsterdam 2018
17.20 - 18.00
Automatically generating your tests from a specification
Have you ever been designed a back-end and give another team responsibility for the front-end or your system? Then you most likely agreed upon some API that the front-end developers could use.
This API is a kind of promise of what the system will do but also flags the limits of the system. It's a lightweight specification, a kind of contract between you and the front-end developers. You need to guarantee that your software follows this specification, otherwise, you're swamped in questions and reported issues. Automatically generating tests from such a specification would, therefore, be really nice to have.
Specifications are changing through the lifetime of the project, the front-end may need different features or the back-end developers come to the conclusion that they cannot implement it in this way. The contract changes, both parties need to be aware! Automatically generated tests show immediately where the system is not compatible with the changes to the API and remove the need to refactor hundreds of existing test cases.
Testing is a major part of all software development - yet no matter how much effort is spent on manually writing test cases, some errors always seem to slip through. Cases which no-one thought to test crash systems late in development or out in the field, revealing errors which cost time and money to analyse, diagnose, and fix.
Property Based Testing enables developers to generate tests from specifications. It enables them to find errors at an earlier stage, lowering costs and improving quality as a result. In this talk, Thomas Arts will use examples to show how to get from a purely syntactic API specification to a specification that can be used to test a simple stateful web service. We will see how shrinking finds tiny examples that provoke errors, making the step from observing a bug to diagnosing it very short indeed.