I offer a Workshop on Testrecorder at XP-Days 2017. Everyone that visits the session, will be presented a refactoring of selected “Legacy Code”-projects following the method:
- Record (Capture some Tests)
- Refactor (Simplify the Code)
- Replay (Execute the Tests)
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.
Which is your naming convention for implementation classes? Do your prefer
Intrinsically I should be pleased about this question – at least someone seems to care about naming conventions … but sorry, both conventions are little more than crap. Unfortunately these patterns are very popular, so my criticism will have little effect. Here you are:
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).
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.
There must be another cure against legacy code than writing tests … Sounds like “There must be another cure against chaos than tidying up”.
Yet for we all know the washing machine, the dishwasher, the hoover robot but not the code cleaner. Why?