The Simple Story Paradox

I’ve recently been following the #isTDDDead debate between Kent Beck (@kentbeck), David Heinemeier Hansson (@dhh), and Martin Fowler (@martinfowler) with some interest. I think that it’s particularly beneficial that ideas, which are often taken for granted, can be challenged in a constructive manner. That way you can figure out if they stand up to scrutiny or fall down flat on their faces.

The discussion began with @dhh making the following points on TDD and test technique, which I hope I’ve got right. Firstly, the strict definition of TDD includes the following:

1. TTD is used to drive unit tests
2. You can’t have collaborators
3. You can’t touch the database
4. You can’t touch the File system
5. Fast Unit Tests, complete in the blink of an eye.

He went on to say that you therefore drive your system’s architecture from the use of mocks and in that way the architecture suffers damage from the drive to isolate and mock everything, whilst the mandatory enforcement of the 'red, green, refactor’ cycle is too prescriptive. He also stated that a lot of people mistake that you can’t have confidence in your code and you can’t deliver incremental functionality with tests unless you go through this mandated, well paved road of TDD.

Getting Started With Spring’s MVC Test Framework - Part 2

The first blog in this mini-series introduced the Spring MVC Test Framework and demonstrated its use in unit testing Spring MVC Controller classes as controllers rather then as POJOs. It’s now time to talk about using the framework for integration testing.

By ‘integration testing’ I mean loading the Spring context into the test environment so that the controller can work with its collaborators in ‘end to end’ tests.

Getting Started With Spring’s MVC Test Framework - Part 1

Newly promoted to the main Spring framework is the Spring MVC Test Framework, which the Guys at Spring claim is a “first class JUnit support for testing client and server side Spring MVC code through a fluent API”¹. In this and my next blog, I’m going to take a look at Spring’s MVC Test Framework and apply it to some of my existing sample code to figure out whether or not it does what it says on the tin.

The API has been designed with two ways of setting up server side tests. These are firstly, with a Spring context file and secondly, programmatically without a context file. The Guys at Spring refer to the programatic method as ‘standalone’ mode.

Setting tests up programmatically

Summary of Testing Techniques Blogs

As I’ve just about come to the end of my series of blogs on testing techniques, today’s blog lists for review purposes my nine blogs on this subject so far - there may be more...

Why You Should Write Unit Tests - Testing Techniques 8

I’ve had lots of reaction to my recent blog on ‘What you Should Test’, some agreeing with me for varying reasons and others thinking that I’m totally dangerous for suggesting that certain classes may not need unit tests. Having dealt with What to test, today’s blog deals with Why you should write unit tests, and today’s example code is based upon a true story: only names, dates and facts have been changed.

More on Creating Stubs for Legacy Code - Testing Techniques 7

In my last blog, I talked about dealing with the badly behaved untestable₁ SitePropertiesManager class and how to create stubs by extracting an interface. But what happens when you don’t have access to the source code of the legacy class because it’s locked away inside a third party JAR file?

Creating Stubs for Legacy Code - Testing Techniques 6

Any one who reads this blog will probably have realised that at present I’m working on a project that contains a whole bunch of legacy code that’s large, expansive, and written without any tests what so ever. In working with this legacy code, there’s been one very badly behaved class that’s all pervasive, which the whole team have tripped over time and time again. In order to protect the guilty, I’ll call it Mr. X although its real name is SitePropertiesManager as it manages the web site’s properties.

Unit Testing Using Mocks - Testing Techniques 5

My last blog was the fourth in a series of blogs on approaches to testing code, demonstrating how to create a unit test that isolates the object under test using a stub object. Today’s blog looks at what is sometimes regarded as an opposing technique: unit testing with mock objects. Again, I’m using my simple scenario of retrieving an address from a database:

… and testing the AddressService¹ class:

Regular Unit Tests and Stubs - Testing Techniques 4

My last blog was the third in a series of blogs on approaches to testing code and discussing what you do and don’t have to test. It’s based around my simple scenario of retrieving an address from a database using a very common pattern:

...and I proffered the idea that any class that doesn’t contain any logic doesn’t really need unit testing. In this I included my data access object, DAO, preferring instead to integration test this class to ensure it worked in collaboration with the database.

What Should you Unit Test? - Testing Techniques 3

I was in the office yesterday, talking about testing to one of my colleagues who was a little unconvinced by writing unit tests. One of the reasons that he was using was that some tests seem meaningless, which brings me on the the subject of what exactly you unit test, and what you don’t need to bother with.

Consider a simple immutable Name bean below with a constructor and a bunch of getters. In this example I’m going to let the code speak for itself as I hope that it’s obvious that any testing would be pointless.

The Misuse of End To End Tests - Testing Techniques 2

My last blog was the first in a series of blogs on approaches to testing code, outlining a simple scenario of retrieving an address from a database using a very common pattern:

Testing Techniques - Part 1 - Not Writing Tests

There’s not much doubt about it, the way you test your code is a contentious issue. Different test techniques find favour with different developers for varying reasons including corporate culture, experience and general psychological outlook. For example, you may prefer writing classic unit tests that test an object’s behaviour in isolation by examining return values; you may favour classic stubs, or fake objects; or you may like using mock objects to mock roles, or even using mock objects as stubs. This and my next few blogs takes part of a very, very common design pattern and examines different approaches you could take in testing it.

Reviewing PowerMock's Features

When you write a blog, you get a feel for those subjects that are contentious and those that aren’t and one of the most contentious subjects seems to be the area of unit test techniques: are you a mockist or a classist? Can you test internal state or private methods? Should you just test behaviour? Just out of curiosity, I recently took a look at Powermock, software with which I have no relationship, and I wrote four simple ‘how to’ blogs on some of its features. The blogs were:

1. Using PowerMock to Mock Static Methods
2. Using PowerMock to Mock Constructors
3. Why Use PowerMock to Mock Private Methods?
4. Testing an Object's Internal State with PowerMock

One of the things I didn’t do was to sum up how useful I thought each of the features were, which led to some constructive criticism, which I broadly agreed with before the authors made their first keystrokes.

Testing an Object's Internal State with PowerMock

Most unit testing focuses on testing an object’s behaviour in order to prove that it works. This is achieved by writing a JUnit test that calls an object’s public methods and then testing that the return values from these calls match some previously defined set of expected values. This is a very common and successful technique; however, it shouldn't be forgotten that objects also exhibit state; something that is, by virtue of the fact that it’s hidden, often overlooked.

Why Use PowerMock to Mock Private Methods?

So far I’ve written a couple of blogs on PowerMock covering some of what I think are its most useful features. Today’s blog takes a look at PowerMock’s ability to mock private methods. At first this struck me as a pretty useless idea. The PowerMock documentation says that you can use it to mock private methods that are called many times during your build process so that you only test them once. My first reaction was does it matter whether or not you execute a piece of code once or a thousand times during a set of unit tests? Usually the answer will be ‘no’ and this feature will be pretty superfluous. However, there is a scenario where is come come in very handy...

Using PowerMock to Mock Constructors

In my opinion, one of the main benefits of dependency injection is that you can inject mock and/or stub objects into your code in order to improve testability, increase test coverage and write better and more meaningful tests. There are those times, however, when you come across some legacy code that doesn’t use dependency injection and held together by composition rather than aggregation.

Using PowerMock to Mock Static Methods

In a recent blog, I tried to highlight the benefits of using dependency injection and expressing the idea that one of the main benefits of this technique is that it allows you to test your code more easily by providing a high degree of isolation between classes, and coming to the conclusion that lots of good tests equals good code. But, what happens when you don’t have dependency injection and you’re using a third party library that contains classes of a certain vintage that contains static methods?

Integrating SureAssert with Existing Projects

I recently blogged about SureAssert’s ability to do automatic, continuous, declaration driven testing using annotations, which could make JUnit test classes obsolete. When picking up any new and useful development tool, the first question asked is usually “how can it help my existing project?” The answer here is that SureAssert integrates with existing JUnit test code, which gives you the benefit of having your existing JUnit tests continuously monitored and executed.

Declarative Unit Testing: Is JUnit Obsolete?

One of the pains in the bum with Test Driven Development is that if (or when) you change a class, you often spend a good deal of time patching up all your unit tests and if you’re a Mockist then it becomes even harder as you have to mess around re-jigging a lot of mock code. So, the other day I was surprised when I came across a new free product that turns the current ideas of unit testing on their head. The surprise came in the form of SureAssert, which as the website says is “an integrated Java unit testing solution for Eclipse”.

ROT13 Encryption

I thought that today I’d tackle the thorny issue of encryption starting with one of the most simple and weakest algorithms available: ROT13. ROT13 is a simple character shift or Caesar (or Caesar’s) cipher. In ROT13 each plain text character is replaced with one that’s 13 characters further along the alphabet. For example: ABC becomes NOP, whilst the plain text characters after M loop around back to the start of the alphabet; hence: MNO becomes ZAB whilst XYZ becomes KLM. Note that only upper and lower case letters in the English alphabet are encoded.