How do you know what to test when writing unit tests? [closed]

Answer 1

well if you think it can break, write a test for it. I usually don't test setter/getter, but lets says you make one for User.Name, which concatenate first and last name, I would write a test so if someone change the order for last and first name, at least he would know he changed something that was tested.

Answer 2

If the Authenticate and Save methods use the properties, then your tests will indirectly touch the properties. As long as the properties are just providing access to data, then explicit testing should not be necessary (unless you are going for 100% coverage).

Answer 3

I wouldn't test the actual setting of properties. I would be more concerned about how those properties get populated by the consumer, and what they populate them with. With any testing, you have to weigh the risks with the time/cost of testing.

Answer 4

Another canonical answer. This, I believe, from Ron Jeffries:

Only test the code that you want to work.

Answer 5

Ideally, you would have done your unit tests as you were writing the class. This is how you're meant to do it when using Test Driven Development. You add the tests as you implement each function point, making sure that you cover the edge-cases with test too.

Writing the tests afterwards is much more painful, but doable.

Here's what I'd do in your position:

1. Write a basic set of tests that test the core function.
2. Get NCover and run it on your tests. Your test coverage will probably be around 50% at this point.
3. Keep adding tests that cover your edge-cases until you get coverage of around 80%-90%

This should give you a nice working set of unit tests that will act as a good buffer against regressions.

The only problem with this approach is that code has to be designed to be testable in this fashion. If you made any coupling mistakes early on, you won't be able to get high coverage very easily.

This is why it is really important to write the tests before you write the code. It forces you to write code that is loosely coupled.

Answer 6

Even get / set can have odd consequences, depending upon how they have been implemented, so they should be treated as methods.

Each test of these will need to specify sets of parameters for the properties, defining both acceptable and unacceptable properties to ensure the calls return / fail in the expected manner.

You also need to be aware of security gotchas, as an example SQL injection, and test for these.

So yes, you do need to worry about testing the properties.