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.
Reference: The Architecture Spike Kata from our JCG partner Johannes Brodwall at the Thinking Inside a Bigger Box blog.
Related Articles :
