Why do you want to do it? Because you make changes / additions to the existing code at some point and not notice that it breaks functionality that worked previously (who tests every functionality they ever implemented).
A good coverage of functionality with unit tests ensures that you will notice that the code you have modified does no longer work the way it used to work. At some point (possibly integrated into your build process) you will run the unit tests and see if the code still satisfies the conditions. That is pretty much what writing unit tests is about:
you declare that, for example, you want a method to return 10 when you pass 5 as parameter #1 and 2 as parameter #2.
Broken tests might be desired (in that case you update the unit tests) or not (in that case you fix your new code).
You might want to look at TDD (test driven development). With that approach you write the tests first (they will all fail at first) ... then you write the code that makes them succeed.
That approach makes sure you don't write extremely cool classes with dozens of options for later use and never actually use half the code.
You also have to think about responsibilities of modules, scenarios and the architecture before you jump into the implementation ... which is usually a good thing:
Showing examples is a little difficult. It depends a lot on your desired workflow how this is set up. I'd google what options there are for unit testing for your programming language of choice and visit its website.
The real beauty of unit tests can be seen when it is integrated into a continuous integration solution. But I guess you have enough input to process already ...