Subscribe to our Erlang Factory newsletter to receive the latest updates and news

Thomas Arts
Professor and co-founder of QuviQ QuviQ AB
QuviQ AB

Dr. Thomas Arts is the co-founder and CTO of Quviq, a small company that produced QuickCheck, as testing tool for Erlang. He has successfully introduced some new technologies in industry, the latest being QuickCheck, a tool for property based testing and aims to support test driven development. Thomas is also an professor at Chalmers University of Technology (Gothenburg) in the area of Software Engineering. He holds a PhD in computer science and after his PhD has been employed at the Ericsson Computer Science Lab (Where they invented Erlang). He worked on program verification and the development of the Erlang programming language. He has also worked in the broad spectrum theoretical computer science, formal methods and industrial case-study research, mainly applying all kind of techniques to systems written in Erlang.

Thomas Arts is Giving the Following Talks
Automatic Testing of TCP/IP Implementations Using Quickcheck

Developing a network stack is difficult. It is highly concurrent
by design, there are many time-related tasks that must be performed, and it must be reasonably efficient to be useful. Testing a network stack is also hard, because it involves using a packet sniffer and looking at long packet dumps. Usually, tests are run using a well known stack as peer, such as the Linux kernel TCP/IP stack. However this approach has some problems. Many errors are difficult to find and to reproduce because they only arise under special conditions. Also, the TCP/IP stacks of the most common operating systems tend to be lax about accepting behaviours by their peers that do not fully conformn to the protocol. These errors would only be noticed when connecting with more simple stacks typical in embedded systems.

In this work we present an automatic test case generator for TCP using Quickcheck. This tester generates packet flows to test specific features of a TCP stack. It then controls the stack under test to run the test by using the interface provided by it (for example, the socket interface), and by sending replies to the packets created by the stack under test.

Because this tool controls the packets that are sent to the stack under test it can simulate situations that are not likely to appear in a normal test.