If all it does is store whatever values its given, I'd say that it's
not worth writing something to test it.  Save your time to code tests
for complex things, actual business rules, etc.

It depends.

The biggest reason for writing tests is to allow somebody else (or you)
to refactor your code and easily tell if they have broken it.

Another reason is that it clearly documents how the class should be used.

Lets say you decide to validate Zip Codes against States... If you have
unit tests, you can easily tell if you have broken the basic behavior.
If you don't have tests, you might introduce bugs in the process.

However, tests are not always a good thing. In this case, they could get
brittle and slow the development process (since, for example, you might
refactor Address away entirely, pull it in from a database, etc).

Unit tests cost time. Bugs cost time. Write the unit tests if they cost
less than the bugs. Let the bugs happen if they cost less than the unit
tests (eg. If you're writing a *truely* throwaway app).

If in doubt, I'd write tests.

And if you're writing so many of these types of classes that you need to
care about whether they need tests, you probably need to rethink your
architecture.

Alun Harford

</long, winding post>

Andy B schrieb:

If you only use some getters/setters on this class i wouldn't spend much
time on unit tests. however, the described class could be improved
considerably.

i would implement it as an immutable type with only getters and a
constructor. this would reduce the problem you have when you change the
zip-code but not the city and the state. remember, even when you change
them one after the other the state of your instance is incorrect during
the modifications. furthermore your type will not be thread-safe.

you will need some rules to verify that zip-code and city actually match
and to ensure that the zip code is in the correct format. so, you
eventually will implement business-rules on this type ...

now, if you add the rules to your setters you'd get some silly
exceptions if the zip doesn't match the city (when changing the zip
after the city) or vice versa.

so, make the type immutable, create business-rules and verify them and
finally test them.

Alain

To be honest I'm a bit ambivalent to this question.

On one hand I advocate testing everything, for various reasons (I'm
getting to those), but on the other hand, a class that holds strings
(struct with fields?), do you really foresee much problems in creating
that class?

My goal for 100% tests is to be able to do code coverage that ends up in
100% coverage. If you can attain that, it's easy to figure out what
parts of your code you're missing a test for, you can just run code
coverage.

On the other hand, I also advocate writing the tests first, so that you
can afterwards check that the class functions according to specifications.

But, if you don't want to, or can't, go to 100% code coverage for unit
tests, you should prioritize your tests, so that you don't spend time
writing tests for one class that really should've been spent on writing
tests for another more important class.

Basically, for each class/code blocks/testable unit, you should decide
on the following two criteria:

1. what is the risk of this code being wrong?
2. what is the consequence of this code being wrong?

If the answer to the above questions are:

1. low
2. little

then write the test to it last.

If on the other hand the answers are:

1. medium to high (complex class)
2. critical showstopping bug (payment system down, ordering system
producing the wrong orders, etc.)

then by all means, test it to death.

To me, it sounds like your class belongs in the first category. Not much
that can go wrong. It might have dire consequences if it goes wrong, but
you also need to decide on what could go wrong. If one thing that could
go wrong was that a field of the class was null, and this could crash
your app with a null reference exception, then it would depend on the
application wether this was "critical" or not.

I don't think anyone but you yourself can really decide wether the class
is worthy of its own test or not.

Personally I would write a test for it, but it would be written towards
the end of the project, given enough time to do it, at least with what
you've told us about it so far.