Open Access. Powered by Scholars. Published by Universities.®
Articles 1 - 5 of 5
Full-Text Articles in Entire DC Network
Tests As Maintainable Assets Via Auto-Generated Spies: A Case Study Involving The Scala Collections Library's Iterator Trait, Konstantin Läufer, John O'Sullivan, George K. Thiruvathukal
Tests As Maintainable Assets Via Auto-Generated Spies: A Case Study Involving The Scala Collections Library's Iterator Trait, Konstantin Läufer, John O'Sullivan, George K. Thiruvathukal
George K. Thiruvathukal
In testing stateful abstractions, it is often necessary to record interactions, such as method invocations, and express assertions over these interactions. Following the Test Spy design pattern, we can reify such interactions programmatically through additional mutable state. Alternatively, a mocking framework, such as Mockito, can automatically generate test spies that allow us to record the interactions and express our expectations in a declarative domain-specific language. According to our study of the test code for Scala’s Iterator trait, the latter approach can lead to a significant reduction of test code complexity in terms of metrics such as code size (in some …
Automated Systematic Testing For Constraint-Based Interactive Services, Patrice Godefroid, Lalita Jategaonkar Jagadeesan, Radha Jagadeesan, Konstantin Laufer
Automated Systematic Testing For Constraint-Based Interactive Services, Patrice Godefroid, Lalita Jategaonkar Jagadeesan, Radha Jagadeesan, Konstantin Laufer
Konstantin Läufer
Constraint-based languages can express in a concise way the complex logic of a new generation of interactive services for applications such as banking or stock trading, that must support multiple types of interfaces for accessing the same data. These include automatic speech-recognition interfaces where inputs may be provided in any order by users of the service. We study in this paper how to systematically test event-driven applications developed using such languages. We show how such applications can be tested automatically, without the need for any manually-written test cases, and effi- ciently, by taking advantage of their capability of taking unordered …
A Comparison Of Laboratory And Vulnerability Evaluation Methods For The Testing Security Equipment, Benjamin Beard, David J. Brooks
A Comparison Of Laboratory And Vulnerability Evaluation Methods For The Testing Security Equipment, Benjamin Beard, David J. Brooks
David J Brooks Dr.
A facility wide security system cannot be tested without causing disruption or creating vulnerabilities within the system. To overcome this issue, individual components or equipment may be evaluated to a priori performance standard. The two common approaches to security equipment evaluations are vulnerability attacks and laboratory testing. Laboratory testing of security equipment can reduce the costs and time associated with evaluations, as well as limiting the subjectivity of the tests. Vulnerability attacks will produce more realistic evaluation results of the whole security system; nevertheless, the data obtained is dependent on the physical attributes and skill of the attackers. This study …
Unit Testing Considered Useful, George K. Thiruvathukal, Konstantin Läufer, Benjamin Gonzalez
Unit Testing Considered Useful, George K. Thiruvathukal, Konstantin Läufer, Benjamin Gonzalez
Konstantin Läufer
Testing is an important part of application development. Hardware engineers, in particular, have a long established history of testing for the obvious reason that it's awfully hard to rebuild a microprocessor every time a bug pops up in the design stage--not to mention the enormous headaches such bugs generate on the software side.
Unit Testing Considered Useful, George K. Thiruvathukal, Konstantin Läufer, Benjamin Gonzalez
Unit Testing Considered Useful, George K. Thiruvathukal, Konstantin Läufer, Benjamin Gonzalez
George K. Thiruvathukal
Testing is an important part of application development. Hardware engineers, in particular, have a long established history of testing for the obvious reason that it's awfully hard to rebuild a microprocessor every time a bug pops up in the design stage--not to mention the enormous headaches such bugs generate on the software side.