Determining what to unit test and what not to

Question

I am still getting to understand Test Driven Development. I have the following requirements for a user registration module of an application.

1. The system must capture the user's firstname, lastname, email address and optionally, postal address
2. The firstname and lastname must be alphabetical
3. The firstname and lastname may not be empty
4. The email address must be a valid address and is mandatory
5. The postal address is optional.

To implement the above in java. I have written the following code:

1. The java bean containing the above fields and having corresponding getters and setters
2. Validation annotation for the above fields
3. A dao for saving a user
4. A user interface for entering the user details.

Question: Which of the above code should be covered with unit tests? i.e The bean's getter and setters, the presence of validation annotations, the ability of the dao to save the user, the presence of the relevant form elements in the UI.

Answer 1

I write tests for things that I reason "can I've done this wrong?". That means I don't bother to test libraries others supplied - only my configurations of them.

Getters and setters - most definitely not. I use Eclipse to generate them, it's not worth testing.

The annotations for validation - I wouldn't test that they, for instance, correctly implement a null check, I rely on that they do what it says on the tin, but I would test the presence of them. Do the right field have them? And if I configured them with a regexp, I would test I got the regexp right.

Another example, if I store my POJO with Hibernate. I don't check that Session.save(myObj) is working, but the stuff I can have done wrong such as transaction boundaries and mapping configuration (are all fields saved) etc.

I find user interface testing really hard. I've many times thought "this time I will" - but anything more complex than a form, and I give up. Using a pattern like MVP means I can inject events to test most of the computational stuff - but there's still the connection to the UI which isn't tested. I usually end up with testing bits of it, complex data handling, things that feel error prone.