Once you catch the automated testing itch you want to write test for everything. But should we use the same strategy for every piece of software? The conclusion that I’ve come to is no. While I’m completely committed to the practice of TDD and aggressive test coverage, I’ve found that legacy software needs to be approached strategically.
Through the years I’ve encountered a recurring requirement. Clients need to log changes to the database for auditing and legal purposes. To satisfy this requirement you could add logging to every save/update/delete call in your code. Or better yet, you could create an aspect that wraps these calls. While these would certainly work Hibernate provides a convenient interceptor.
In this article I will show you how to add a simple logger to Hibernate.
Spring is an essential part of my technology stack. I cann’t image providing quality software that doesn’t leverage an IoC container. However, decoupling components requires some amount of configuration. Whether this is accomplished through annotations or XML, it’s fairly easy to mess up. Fixing these missing or incorrect configurations doesn’t take very long. The real question is how quickly can you identify these errors?
This question of how long, is a feedback loop question. Unfortunately many teams wait until they fire up the application server to see if their Spring context is wired correctly. This is too late.
One of our clients suffered from this very issue. Due to environmental constraints they could not run automated, in-container tests that would have identified misconfigured beans. After repeatedly committing stupid configuration mistakes, I decided that I would write a Spring wiring test. As I began to write this I encountered five problems.
With Mockito 1.8.3 or higher you can significantly reduce your test code setup.
Transactions are an essential component in enterprise software development. When your application works properly you rarely think about transactions. However, when things go wrong debugging transactions can be quite challenging. Instead of being reactive we need to proactively test our transactions.
When I first got into the software industry I was a manual tester. Those years of repetition and tedium drove me to the world of coding and automation. As a software developer I am committed to automated testing. If a feature is worth coding it is worth testing. Automated tests have positioned me to be proactive instead of reactive. Nevertheless, transactions are quite challenging to test.