I started to work on a tool for Change Impact Analysis. It is called Berta at the moment.
We have plenty of tools that are great in answering a question "If I see this error here, which class on the backend I should fix?" But there is not yet a tool to answer another question: "What could possible break if I refactor this little method?" This question is very important to ask any time you are about to refactor something. And I have seen many companies and teams to be afraid to touch any specific piece of code because "Nobody knows what can go wrong if you change it".
Static code analysis tools are a huge help there. But they have their limit. Modern applications tend to be big and consist of loosely coupled bits and parts. The actual execution path in runtime is influenced by some configuration files (XML, Yaml, plain text), driven by scripts (JavaScript, Groovy, Lua) and are inherently asynchronous. Even when the best static code analysis tool tells that this method is not used anywhere, you still can not be sure. What if somebody calls it via reflection?
I started to work on a tool that will answer this question. It spies on a JVM in runtime and keeps track of all methods touched. The tools has a simple plain text API, through which it can dump that collected data. Idea is very simple. While you are running your manual or automated test suite, you use API to let Berta know which test or business function you are about to execute.
So far I only finished the Java Agent, which is the spying part. It is small and written to have minimal impact on the application in runtime. The other part would have an UI, a convenient REST API and will save data gathered by Java Agent to a Database.
And today I have used my tool in a real software development situation. I had a small bug against a huge and unfamiliar web application. I was confident that the fix will be a one line change, but I was not able to find that one damned line. It was the case of JavaScript and Database configuration influencing the execution and I did not want to spend too much time learning the way that huge application configures itself. Oh, and it was a distributed application as well, so I was not even sure which JVM is running that broken piece of code.
I connected Berta to all suspected JVMs and manually reproduced the bug. Since Berta supports tagging, I ended up with a very short list of methods that I had to check for correctness. In the next 5 minutes the bug was fixed.
I am very excited. My motivation to finish the UI part is restored and I hope the tool will be available for anyone to use by the end of Summer.