The tactics for unit testing vary depending on the "test unit" being tested in that test.
If the test unit is an implementation of a function that performs a calculation based on a combination of inputs and its current state, then a good unit test would be to put that object into the defined state, and then call the function and verify its output is the golden data
If the test unit is responsible for deciding which object from a list it should return, then a good unit test would be to force populate that list with its (mock?) objects, and then verify that the expected object instance was returned.
Some units being tested do not match the "golden value" style of testing.
Consider, a function which is responsible for sequencing a series of calls to other objects. In this case, you are likely to create a mock/fake objects to receive these calls, and then instead of comparing golden values, you are checking that these objects were called with appropriate parameters.
Some unit tests are written to verify the absence of behaviour
Consider how you would validate that a function that needed to make a function call if certain conditions were met. Its as important to validate that this call does not occur if the conditions are not met, as it is to verify its called when they do meet.
Finally, sometimes verifying that a function does not generate exceptions across a wide range of inputs can be important.