The Architecture Spike Kata

Do you know how to apply coding practices the technology stack that you use on a daily basis? Do you know how the technology stack works? For many programmers, it’s easy enough to use test-driven development with a trivial example, but it can be very hard to know how to apply it to the problems you face every day in your job.

Java web+database applications are usually filled to the brim with technologies. Many of these are hard to test and many of these may not add value. In order to explore TDD and Java applications, I practiced the Java EE Spike Kata in 2010. Here’s a video of me and Anders Karlsen doing this kata at JavaZone 2010.

A similar approach is likely useful for programmers using any technology. Therefore, I give you: The rules of the Architecture Spike Kata.

The problem

Create a web application that lets users register a Person with names and search for people. The Person objects should be saved in a data store that is similar to the technology you use daily (probably a relational database). The goal is to get a spike working as quickly as possible, so in the first iteration, the Person entity should probably only contain one field. You can add more fields and refactor the application later.

The rules

The most important rules are Robert Martin’s three rules of Test-driven development:

  • No code without test (that is, the code should never do something that isn’t required in order to get a test to pass)
  • Only enough test to get to red (that is, the tests should run, give an error message and that error message should correct)
  • Only enough code to get to green (that is, the tests should run and not give an error)
  • (My addition: Refactor on green without adding functionality)

Secondly, application should be driven from the outside in. That is, your first test should be a top-level acceptance test that tests through http and html. It’s okay to comment out or @Ignore this test after it has run red for the first time.

Lastly, you should not introduce any technology before the pain of not doing so is blinding. The first time you do the kata in a language, don’t use a web framework beyond the language minimum (in Java, this means Servlets, in node.js it’s require('http'), in Ruby it means Rack). Don’t use a Object-Relational Mapping framework. Don’t use a dependency injection framework. Most definitely don’t use an application generator like Rails scaffold, Spring Roo or Lift. These frameworks can be real time savers, but this kata is about understanding how the underlying technology works.

As a second iteration, use the technologies you use on a daily basis, but this time set up from scratch. For example, if your project uses Hibernate, try configuring the session factory by hand. By using frameworks in simplest way possible, you’ll both learn more about what they bring to the table and how to use them properly. For complex technology like Hibernate, there’s no substitute for deeper understanding.

What to expect

So far, I’ve only done the Architecture Spike Kata in Java. But on the other hand, I’ve done it around 50 times together with more than ten other developers. I’ve written about how to get started with the Java EE Spike Kata (in Norwegian) on my blog before.

This is what I’ve learned about working with web applications in Java:

  • Most Java web frameworks seem to harm more than they help
  • Hibernate is a bitch to set up, but once it’s working, it saves a lot of hassle
  • Using TDD with Hibernate helped me understand how to use Hibernate more effectively
  • I’ve stopped using dependency injection frameworks (but kept on using dependency injection as a pattern)
  • I have learned several ways to test web applications and database access independently and integrated
  • I no longer have to expend mental energy to write tests for full stack application

The first time I write this kata with another developer, it takes around 3 to 5 hours, depending on the experience level of my pair. After running through it a few times, most developers can complete the task in less than an hour.

We get better through practice, and the Architecture Spike Kata is a way to practice TDD with the technologies that you use daily and get a better understanding of what’s going on.

Comments:

Anders Karlsen - Dec 24, 2011

I first tried in this kata in early 2010. I did it once then. Then I was going to demonstrate it at JavaZone 2010, and I practiced it numerous times, both using pair programming and programming alone. I have learned several useful lessons from this:

  • Mocking. Since you start without a backend you are forced to mock that. You also need to mock the server request and response. I have used Mockito for this and thus was forced to learn it well * Hibernate. How often do you setup Hibernate? Once every project if you are (un)lucky? This has forced me to learn it, and learn it well. If I need to test something Hibernate related, I can quickly setup a test environment for it. * I have done the kata with around ten people. Each time I do it with a different person, I learn something new. Maybe a new keyboard shortcut in the IDE, or some new way of doing something. * When I setup a new development I usually do this kata on it. Then I can setup my preferred keyboard shortcuts and templates. It also serves as a good test, indicating that the environment is correct.

So in my opinion there are many useful lessons to learn from this kata, and I would recommend everyone to check it out!