Occasionally unit testing is more complex than with simple types, e.g with
- results from webservice interfaces (REST/SOAP)
- orm-mapped database results
- parse trees
- graphs or trees in general
Such types are deeply (or recusively) nested and thus not easily validated. It is easier when using the right tool - e.g. with the IsEquivalent-Matcher of XrayInterface …
Test Generation in Java - an Overview
The time has come to summarize my research on test generation in Java. One year ago I started with a presentation “Testgeneration in Java” at several conferences and meanwhile I can present the essence of these presentations …
Test Generators - State of Technology
Maybe an overview of testgenerators is interesting to you. A quite complete list could be found on the summary of Zoltán Micskei about Code-based test generation. Most of the listed projects are mainly of academic value - fine for example code, yet not fit for practice.
Regular Expressions in Java
I used Java regular expressions (
java.util.regex) for years uncritically. University taught me that regular expression are efficient.
Some day in my project I had the challenge to search a large amount of words (>1.000) in a large number of documents (>10.000). I remembered college and instead of searching each word in each document. I decided to search in each document for the regular expression
<Word1>|<Word2>|...|<Word1000>. That should have been far more efficient than searching each word in each document … However, regular expression is not regular expression and the fast automatons known to me from college are not the same that are provided by Java.
Exact String Matching in Practice
Initially I was interested in string search from an academic view point - just understand the algorithm and be able to implement it. After this passion culminated in the project (StringSearchAlgorithms), I began to compare it to others …
It became obvious that many algorithms worked in theory, but were slow or even failing in practice. Actually most academic algoirthms on string search are optimized for a certain situation dependent on:
- programming languages and APIs
The following sections describe the challenges string search is confronted to in practice.
Testrecorder – Next Steps
After Presenting at Karlsruher Entwicklertag it is time to write a few words about the future of Testrecorder … Testrecorder is a Java tool vor recording runtime situations. Recording means, that we intercept method invocation and capture the state before and after the invocation. From this captured state we generate JUnit-tests.
Naming of Interfaces and Implementations
Many of you are probably familiar with code containing an interface
FormDataValue and implementation classes
FormDataValueImpl. However I received consent on my complacent criticism, accompanied by an excuse like: “Our team decided not to follow a naming condition like e.g.
I feel my criticism was misunderstood? There are almost always more than two options in naming classes. Why do some teams only find these two? I will try to analyze the problem more deeply …
String Search in Java (using the JDK-API)
String search is a common problem, appearing every time we check that a string is contained in another. The JDK Standard API provides some basic functionality for this, yet there are more efficient algorithms for larger patterns and larger texts.
In this posting I present an overview over the string searching features of the Java API, starting with a short definition of string searching and ending with an overview of libraries that provide more features for string searching (more details will follow in later postings).
Accessing Private Fields and Methods with XRayInterface
This posting is about accessing private fields and methods, by adopting a foreign interface to a given java class (not already implementing the given interface). Why? Yet, in my former posting about Repairing Legacy Code I mentioned the challenge of accessing hidden state (private fields) before and after method invocations.
Repairing Legacy Code - Automatically
Many Projects already use automated regression testing. Unfortunately we cannot rely on this in situations that afford them most, for maintaining foreign (untested) legacy code. Here I do not only wish for automated regression tests, I also wish for automated test generators. Why does such a tool not exist?
I was speaker at several conferences. A list of my talks are found at Talks.