And that's how you do it. Ryan, good job explaining all the non-test-writers why someone should write any tests. I suggest you don't do it any other way because it is going to take you more time and more headaches. It takes you a couple of minutes anyway, saves you a lot of trouble and in the end huge amount of time on testing.
Once your unit tests are done and you start gluing objects together, start writing integration tests in similar manner.
One thing only: I have seen people write tests for getters and setters, and I don't think that is necessary, because there is no functionality in these methods, so why do it?

True, but it doesn't take a lot of time to test setters and getters so I do it anyway. You usually take for granted that these methods work properly, so if you ever had a bug in a getting (ie. returning the wrong private variable my mistake), it's probably the last place you'd look.

Testing them well ahead of time means you don't have to worry about that code in the future. I usually only have one test for both, so the work is minimal: set a value and then make sure you can get it back.

To add to the getter / setter point. Yes, test drive.... for two reasons...

1) It is possible to break - so test it. The reason for having getting and setters are to avoid exposing the variable directly is to hide the fact that you are infact using a variable... perhaps these methods become more complex internally - your unit tests should hold.

2) You will think twice about whether or not you need the get / set methods in the first place. As opposed to just 'hey, I have a variable - lets wrap a get/set around it', you think 'no one needs to get this variable directly, so i'm not going to expose it'. And then if / when someone else will need access to the variable, you can think 'well, can they set it null, or negative, etc' and you can build your tests around that.

This post post actually stemmed from a conversation I shared with Ryan when he came to visit deloitte. I was actually asked the question, what is the overhead.

Philosphy (sp) aside, the pure mechanism of *getting* something done, I pegged it at 25% more work to test-drive your code. The question itself is about as useful as 'What is the overhead of following a receipe to bake cookies?'...

That's a good analogy actually. If you baked cookies without a recipe it would probably take less or more time depending on the quality you personally strive for and how good you are at guessing (remembering the recipe from memory is still using the recipe).

A recipe gives you great cookies every time. Would you eat cookies that were made without a recipe? They'd probably taste like crap. Same goes for code without tests -- ultimately the person using the code isn't satisfied (no tests to verify the API contract OR that the code actually works).

TDD and unit testing philosophy aside, the truth is that it will take me longer to write a method without tests because I will continually have no confidence in it. Nevermind the time it will take the maintain or change it later! That's why I'm always emphasising long-term thinking.

I'm getting to the point now where it is actually FASTER to write a method with tests than without them, even though I'm producing more code in total. I believe that experienced TDD people can produce working methods at a much faster rate than non-testers if they practise enough even though they have to write method code as well as testing code.

Lines of code is a crap metric, even to extrapolate to time. There are too many other factors. Stop thinking in lines of code and think how long did it take to create a "method I trust"? Without tests the goal is elusive.

Right on!

Writing test is a really important part of writing software. However, I think it's a lot harder to write unit tests in some cases. For many methods, it makes a lot of sense, and will probably save you a lot of work.

However, when doing our fourth year project, we found that writing unit tests was very hard. When running a method that would retrieve data from the database, and put in an object to make it easier to use, it is very difficult to do.

Getting a single record, and testing that the returned object, contained the information it was supposed to contain, required making an object, with the information, and then checking that the retrieved object, had the same info as what was expected.

This gets increasingly difficult as you have to deal with returning collections of objects, ensure that all the correct data is returned.

Of course, storing data in the database creates the same problems, you can store something, the database updates, but you may forget to set one column, so, your test would have to read the data back out of the database, and make sure everything was properly written to the database.

Is there a better way to go about testing this sort of thing?

Testing databases is a common theme on Andrew's blog. Personally I don't have much experience with it.

AudioMan's "repository" is database-like but it is made with Java collections so it's a lot easier to load with test data. Unfortunately it doesn't understand SQL. :)

Wouldn't a slightly naive way to test a database be to create objects (with boundary values), write them to the database, read them back, and then do a .equals on them?

Yes, this is relying on your equals being correct, but that's an assumption at that point you should be able to make.

When ever you find that you are having a hard time testing your code, that usually means that it can do with a refactor. There are MANY ways to do anything in code, and some are a lot easier to test than others.

One of the things in my eXtream cookbook is how to test databases. One of the tricks that they do is to have a method that returns a db connection object. Have that apart from any code you have. That way you are able to use mock objects when you override the getConnection method (returning a mock db connection). Also, if you mock out some of your calls, your tests will run faster and you won't have to actually be connected to a database to run them or incur the overhead of setting up the db in a known state.

They show code like this:
public void getAccount(Account acc) {
  // get db connection
  // use db connection
  return account;
}

and they change it to:
public void getAccount(Account acc) {
  return getAccount(getDBConnection(), acc);
}

private Account getAccount(DBConnection conn, Account acc) {
  // use db connection
  return account;
}