Quviq (Sweden)

Property-based testing tools test software against a specification, rather than a set of examples. This tutorial paper presents five generic approaches to writing such specifications (for purely functional code). We discuss the costs, benefits, and bug-finding power of each approach, with reference to a simple example with eight buggy variants. The lessons learned should help the reader to develop effective property-based tests in the future.

We present a framework for automatic grading of programming exercises using property-based testing, a form of model-based black-box testing. Models are developed to assess both the functional behaviour of programs and their algorithmic complexity. From the functional correctness model a large number of test cases are derived automatically. Executing them on the body of exercises gives rise to a (partial) ranking of programs, so that a program A is ranked higher than program B if it fails a strict subset of the test cases failed by B. The model for algorithmic complexity is used to compute worst-case complexity bounds. The framework moreover considers code structural metrics, such as McCabe's cyclomatic complexity, giving rise to a composite program grade that includes both functional, non-functional, and code structural aspects. The framework is evaluated in a course teaching algorithms and data structures using Java.

Random testing is increasingly popular and successful, but tends to spend most time rediscovering the ``most probable bugs'' again and again, reducing the value of long test runs on buggy software. We present a new automated method to adapt random test case generation so that already-discovered bugs are avoided, and further test effort can bedevoted to searching for new bugs instead. We evaluate ourmethod primarily against RANDOOP-style testing, in three different settings our method avoids rediscovering bugs more successfully than RANDOOP and in some cases finds bugs that RANDOOP did not find at all.

AUTOSAR (AUTomotive Open System ARchitecture) is an evolving standard for embedded software in vehicles, defined by the automotive industry, and implemented by many different vendors. On behalf of Volvo Cars, we have developed model-based acceptance tests for some critical AUTOSAR components, to guarantee that implementations from different vendors are compatible. We translated over 3000 pages of textual specifications into QuickCheck models, and tested many different implementations using large volumes of generated tests. This exposed over 200 issues, which we raised with Volvo and the software vendors. Compared to an earlier manual approach, ours is more efficient, more effective, and more correct.

Data types are the core of many applications, and libraries offering implementations of data types should better be solid and well tested. Testing purely functional data types with QuickCheck provides a complete test method for data types, but establishing a complete test method for data types with side-effects is still an open issue. In this paper we show how we can use a stateful QuickCheck model to establish a complete test method for any data type. Considering side effects allows us to move from the purely functional world to the imperative world, as needed to face the testing of data types implementations in languages such as C. We therefore applied our method to some of the data types provided by the well-known GNOME Glib library.

We address the problem of testing and debugging concurrent, distributed Erlang applications. In concurrent programs, race conditions are a common class of bugs and are very hard to find in practice. Traditional unit testing is normally unable to help finding all race conditions, because their occurrence depends so much on timing. Therefore, race conditions are often found during system testing, where due to the vast amount of code under test, it is often hard to diagnose the error resulting from race conditions. We present three tools (QuickCheck, PULSE, and a visualizer) that in combination can be used to test and debug concurrent programs in unit testing with a much better possibility of detecting race conditions. We evaluate our method on an industrial concurrent case study and illustrate how we find and analyze the race conditions.

Abstract During the retreat of the Late Weichselian ice margin, a narrow ice tongue filled the upper Klaralven valley in central Sweden. An inlet of the sea, about 150 km long and only 2 km wide, replaced the ice tongue. The sedimentation in this inlet can serve as an example of the development of a river valley in a formerly glaciated area. Against its eastern side, meltwater from the tributary valleys built up glaciofluvial deltas. Their distal, silty sediments filled the valley only partly downstream from the deltas. During the course of the isostatic rebound, braided streams developed and eroded the sediment surfaces rising above the sea‐level. The sediments were redeposited as secondary deltas, which eventually filled the valley up to the corresponding sea‐level. When the entire valley had been filled with silty sediments, a meander pattern developed, controlled by a bedrock threshold at the lower end of the upper Klaralven valley. The resulting stratigraphy in the bottom of the valley is a thick sil...