A good reason to write tests for seemingly trivial code like that is if you're implementing an API that others will use. I've re-factored a class that implemented a public API and been saved by trivial tests that pretty much just tested getters/setters.
But there's a time and place for everything. I rarely pass 95% test coverage, the remaining 5% are usually not worth pursuing.
If you're using tests to check your API integrity, ok, but writing tests by hand for getters and setters written by hand would be disgusting. Hopefully a very minor declaration in the code can automatically create all the tests.
I feel this is the responsibility of an audit system and not the code itself. I have never understood why people write code to verify a contract when it should be done as a rule in a proper SCM system.
A better process is to write or purchase plug-ins for your SCM system that audit all commits and either notify of a contract violation or refuses commit without a supervisors override. Enforcing contracts is not the domain of custom code it is the domain of SCM and therefore should be implemented at an SCM level. This way you write it once and everyone benefits whereas with test you are a. writing test for every contract and b. leaving in the hands of the current developer to ensure the contract is met. Further by having it audited you can build a process around that audit to guarantee that the issue is accounted for.
I am not sold on TDD, but I have not thrown it out as snake-oil yet either. It is in no way the harbinger of quality it was heralded to be, but logically there are some places that it seems like it can and does help but my general feeling about it in the way that it is sold (test everything), is that it is a wast of time.
But there's a time and place for everything. I rarely pass 95% test coverage, the remaining 5% are usually not worth pursuing.