testing

If you’re having trouble testing legacy code, mock a logger

8 Comments

I was working on some legacy code (“legacy” meaning it has no automated test coverage) and I really wanted to write some automated acceptance tests for it.  The problem is, I could not think of a way to do that without refactoring the code first.  I did not want to do this because “it was already working” and the refactoring could have introduced new bugs.  I had a chicken and egg problem: I didn’t want to modify code until I had automated tests but I had to modify code to write the automated tests.  Which comes first?

I ended up using a trick that minimally changes the production code, actually improves the production code base, and allows me to write automated tests.  It’s these two simple steps:

Continue reading →

11 things I learned about TDD by looking at the tests in the JUnit source

2 Comments

JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and is one of a family of unit testing frameworks which is collectively known as xUnit that originated with SUnit.

JUnit was originally written by Erich Gamma and Kent Beck. The latter literally wrote the book on Test Driven Development.  I thought it would be worthwhile to look at some of the tests in the library and draw attention to some interesting things about them because it may change people’s ideas of how to practice TDD.

Continue reading →

To those that advocate manual tests instead of automated tests

3 Comments

There are people out there who are not the biggest fans of automated tests.  They think they cause more trouble than they are worth.  I can definitely sympathize with that perspective. In fact, I will readily admit it can be completely true.  A bad automated test can be worse than no test.  But, I’ve worked on projects that had a lot of good automated tests and I think they were better off for them.

There are people out there who think writing all these automated tests is usually more trouble than it’s worth.  The alternative to automated tests is to “run your software frequently in a live scenario to test the features as they’re being deployed“.  But, I have some questions for the people that feel this way:

Continue reading →

For legacy systems, I really wish Java had monkey patching

Leave a comment

A big part of my job is maintaining old code bases.  Unfortunately, it’s rare that these code bases were written with testability in mind.  As a result, I start with very little confidence in the changes I’m making: I’m not sure how the code works so I can’t safely say that my change are safe.  In my opinion, the best way to gain confidence in a code base is to write automated tests for it.  But usually easier said than done.

Here’s a problem I always have to deal with: I can write a bunch of automated tests for the legacy system but the tests will eventually access a database or call a remote API that is super slow.  Before I know it, my tests take 10+ minutes to run.  Once that happens, I run them less frequently because the wait is a pain, and when that happens, it takes me longer to notice if I’ve introduced a bug.

Continue reading →

How to mock out a deeply nested class in Spring without going insane

Leave a comment

Lets say you have a bunch of classes that call each other like this:

Here, Root  calls Middle  which calls End  which calls Database .  If you would like to test from Root , and want to mock out the Database how can you do that in Spring?   Spring doesn’t make this easy. But I have figured out how to do this in a way that I consider satisfactory.

Continue reading →