In response to,

http://blog.obishawn.com/2008/06/why-you-should-have-100-code-test.html

“Why would you trust your programming language/framework/environment [to write a simple get/set operation]?  Programming languages are software and thus can contain bugs too.”

http://www.ytechie.com/2008/06/unit-tests-are-for-functionality-not-code.html

“I’m not sure why anyone would say that you shouldn’t be testing your properties. Don’t you want to make sure they work?”

  1. “Come up with a rough design in your head
  2. Write unit tests to test a required piece of functionality
  3. Write the code to provide that functionality
  4. Verify that the unit tests pass, fix the code as necessary
  5. Refactor as necessary
  6. Run a code coverage tool, and get as close to 100% as possible using one of the methods I mentioned previously.
  7. Go to #2 and repeat as necessary”

 

1. Write a test for simple setter/getter because you don't trust yourself, your code or your language framework and have an obsessive personality
2. Realise that you don't trust your NUnit framework either and write some unit tests against your unit testing framework (i.e. you sure need to Assert that your Asserts are Asserting what you need to Assert and then Assert that this is working)
3. Run your new meaningless tests and make sure that they all fail
3. Write just enough code to pass the tests
4. Run the tests again to see them pass (yeah!)
5. Repeat

OR

1. public string Name { get; set; }
2. Go Home Early