Skip to main content

Example Driven Development

This article is the first in a series about Test Driven Development. A test is an example of what a program should do. Examples make the requirements concrete, so they become easier to understand. I will show how examples can be used for requirements, manual testing and unit testing.

I am currently working on automatic order handling for a client. I will implement a servlet with the following tasks:
1. Decode input parameters from a web page.
2. Generate an encrypted license with some of those parameters.
3. Store the license in a database. I can model this database as I want.
4. Store customer data in another database. This database schema is "carved in stone".
5. Send the license as an email to the user.

This is a small project, where I will implement, test and deploy the servlet myself. If it doesn't work, my client will lose customers, and I will be responsible.

So how can I make sure this doesn't happen?

I don't trust myself to make so good quality that there won't be any problems. So, I need to do thorough testing. I will make unit tests, but how do I make good ones?

Unit testing is important, but it's not enough. There are always some issues that don't show up until manual testing. I also need to test the integration between my program and other components manually. But how do I make good manual tests? Do I need to write a formal test specification for this simple program?

I think I do. I need to discuss the requirements with my client, and some examples of what the program is supposed to do is the best way to do that. By making a few concrete examples, I can make sure there are no misunderstandings, and that no requirements are missing. I'm sure there will be some misunderstandings anyway, but that's why I'm going to test it.

I'll use this test specification both for manual testing and as basis for the unit tests. That way, I'll have good unit tests that cover the functionality well, and there hopefully shouldn't bee too many surprises when it comes to integration testing.

I start by writing down 2 examples that the servlet should handle. For each example, I will list the input parameters, output values and any changes to the databases. It doesn't take long to write these down on a piece of paper, and it will be very much worth the effort.

Example 1: A customer orders 1 license of type "Enterprise"

Input
product_id   = (ask the client what the product id is)
quantity = 1
company_name = Dot Com Inc
email = john@dotcom.com
I have already identified a very important question I need to ask my client: What are the product ids that the servlet will receive?

License Content
type         = Enterprise
company name = Dot Com Inc
email = john@dotcom.com
expires = 3/25/2009
License Database
Insert a license with the following values:
type         = Enterprise
company name = Dot Com Inc
email = john@dotcom.com
date = 3/25/2008
expires = 3/25/2009
Customer Database
(I need to ask the client about this.)

Email
to         = john@dotcom.com
subject = License
content = Please find attached an Enterprise license to
Dot Com Inc and email john@dotcom.com.
attachment = enterprise.lic
Example 2: A customer orders 1 license of type "Basic"

Input
product_id   = (Ask the client)
quantity = 1
company_name = Dot Com Inc
email = john@dotcom.com
License Content
type         = Basic
company name = Dot Com Inc
email = john@dotcom.com
expires = 3/25/2009
License Database
Insert a license with the following values:
type         = Basic
company name = Dot Com Inc
email = john@dotcom.com
date = 3/25/2008
expires = 3/25/2009
Customer Database
(Ask the client.)

Email
to           = john@dotcom.com
subject = License
content = Please find attached a Basic license to
Dot Com Inc and email john@dotcom.com.
attachment = basic.lic
Now, I need to go through these examples with my client.

When I talked to the client, the he pointed out that it is possible to order multiple licenses of the "Enterprise" product at once. I hadn't though about that. Together, we discussed how to handle this.

In the next article, I will write about how to implement and unit test the servlet.

Comments

Popular posts from this blog

Database dump with Java

I need to update a database that is created by PHP. The problem is that I am not a PHP coder, but a Java coder, and I need to use some other Java libraries to get the job done. So how can find out exactly which tables to update and how? It would take me weeks to search the PHP code, and I still wouldn't be sure if I got it right.

The first step is to install a clean application on my computer. There is no user data in the database, so if I perform commands like creating a user etc in the web application, I can look at what changed in the database. I'm sure that could be done in MySQL, but I'm not an expert on that either. When the only tool you have is a hammer, everything looks like a nail. So, I'll use Java for that to.

So, I wrote a small Java application that produces exactly the output that I need. It reads metadata from the database to find all tables and columns, lists that metadata and the content of all the rows.

Here it is:import java.io.FileNotFoundException;
im…

The Future of Programming

The problem with abstractions Programmers are experts in abstract thinking. To program is to generalize: A method is a general specification of different execution paths. A class is a general specification of objects. A superclass is a generalization of several classes.

Although our minds are capable of abstract thinking, concrete thinking is more natural, and concrete examples are the foundation for abstractions. For instance, how do you teach children what a car is? You don't give a definition like: 'A car is a wheeled motor vehicle used for transporting passengers.' Instead, you point at a car and say: 'Look, a car!' After seeing a few cars, the child understands what a car is.


Notice what I just did! I started with a general principle and then gave an example. Which part of the paragraph above is easier to understand, the first sentence (general) or the rest (example)?

Einstein said that examples is not another way to teach, it is the only way to teach. It is…

The Pessimistic Programmer

I decided to change the title of this blog to "The Pessimistic Programmer". Why? Am I a depressed person that thinks nothing will work? No, I am an optimist in life. Something good is going to happen today :-) But in programming, something will surely go wrong.

I don't actually view this as pessimism, but as realism. I want to be prepared for the worst that can possibly happen. Hope for the best, prepare for the worst. But my wife explained to me that pessimists always say that they are just being realistic. So, I might as well face it: I am a pessimist.

I think a good programmer needs to be pessimistic; always thinking about what can go wrong and how to prevent it. I don't say that I am a good programmer myself. No, I make far too many mistakes for that. But I have learnt how to manage my mistakes with testing and double checking.

Über-programmers can manage well without being pessimistic. They have total overview of the code and all consequences of changes. But I'…