Eiffel: the language
Test input generation with java PathFinder
ISSTA '04 Proceedings of the 2004 ACM SIGSOFT international symposium on Software testing and analysis
Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering
Feedback-Directed Random Test Generation
ICSE '07 Proceedings of the 29th international conference on Software Engineering
From developer's head to developer tests: characterization, theories, and preventing one more bug
Companion to the 22nd ACM SIGPLAN conference on Object-oriented programming systems and applications companion
Companion to the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications
JAxT and JDI: the simplicity of junit applied to axioms and data invariants
Companion to the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications
Testing with concepts and axioms in C++
Companion to the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications
The axioms strike back: testing with concepts and axioms in C++
GPCE '09 Proceedings of the eighth international conference on Generative programming and component engineering
Axiom-Based Transformations: Optimisation and Testing
Electronic Notes in Theoretical Computer Science (ENTCS)
Testing techniques in software engineering
Testing techniques in software engineering
Testing polymorphic properties
ESOP'10 Proceedings of the 19th European conference on Programming Languages and Systems
Proceedings of the 2013 International Symposium on Software Testing and Analysis
Hi-index | 0.00 |
Writing developer tests as software is built can provide peace of mind. As the software grows, running the tests can prove that everything still works as the developer envisioned it. But what about the behavior the developer failed to envision? Although verifying a few well-picked scenarios is often enough, experienced developers know bugs can often lurk even in well-tested code, when correct but untested inputs provoke obviously wrong responses. This leads to worry. We suggest writing Theories alongside developer tests, to specify desired universal behaviors. We will demonstrate how writing theories affects test-driven development, how new features in JUnit can verify theories against hand-picked inputs, and how a new tool, Theory Explorer, can search for new inputs, leading to a new, less worrysome approach to development.