And while this technique is an outgrowth of my involvement with TDD, this particular technique can be used with or without TDD.
For most of my career, I’ve always liked to develop applications from the top down. That is, get the GUI up first. Don’t make it work. Just get a picture up that you can show to the client.
This isn’t the "trick" I have in mind for improving your speed. But if you aren’t already doing this, the trick won’t help you much.
The reason "Presentation First" is so important is because of a simple truth I’ve come to realize over the years: "No one really knows what they want until they see it." This is particularly true in software development because, try as we have over the last several decades, we still have not come up with a way of showing in pictures what it is we are going to build.
The other reason developing the GUI first is important is because it gives the client a sense that you are making rapid development. It is amazing how much time you’ll have without interruption when you’ve been able to show something that looks really close to the real thing.
The next step in my development cycle typically involves attaching data to the presentation. Most of the programmers I know do this by making whatever REST call they need to make to the server and displaying whatever they get back. There are at least three problems with this.
First, as the data in your database changes, what displays in your presentation changes. If you are working with a local database that you have complete control over, that is a minor problem. But if you are, as so many of my clients are, using a common development database, you can’t be sure that the data you are playing with won’t change.
Second, you really can’t be sure that what you are displaying is actually the correct fields unless you go into your database and change the contents of the fields to represent what the fields contain so that you can display that on your data.
Finally, developing in this way is going to be much slower than it needs to be.
Here’s the deal. The way most of us develop applications, once we get to the part where we need to attach some data, we attach it directly to the REST end point. At the very least, this slows our development time down because every time we load the app to make sure it is doing what we had in mind, we have to wait for it to load the data from the server as well.
But it didn’t matter because I mocked out the data on the client side until the server side data was ready.
In fact, I was able to work ahead of the guy who was providing the data BECAUSE I was mocking out the data. The project manager spent most of that contract worried that I would end up stalled because the data wasn’t ready and I spent the same amount of time assuring her that I wouldn’t get stalled until the ONLY thing I had left to do was hook the application up to real data.
But in this particular Java environment, there is an additional hurdle. If I were to develop this application the way most of my peers are developing, I would need to build the application into JAR, WAR, and EAR files and copy those files over to the JBoss server. While I have created a script for this using Node.js and NPM, the time this takes is a bit excessive.
So instead, what I’ve done is I’ve created a separate project for the bits I’m working on. I’ve setup an Express server using Node.js and installed proxy middleware as my last route handler. It is setup to point to the JBoss server for anything it can’t find under Node. So, any files I need that have already been built, I can grab from JBoss, while all of my work runs under Express.
I have the added advantage of being able to switch between my local mock data and the real data simply by loading my local data when I want mocks or the remote data when I want the real deal. Kind of like you might do with a DI container in .NET only on the client side.
TDD Becomes Trivial
And now that I’m working with known, mock data, implementing Test Driven Development is trivial. Well, for me it is trivial. You still need to make sure you write testable code. But, at least you don’t have to worry about the data part of TDD.