It's a lot simpler that you think it is. You should be able to infer from the analysis what each method of do, e.g. what output you should get when you give it whatever input. Unit testing means that you make another class which is gonna use the method of the class (or of a group of classes, or of a chunk of code, etc) you are trying to test end verify that the output you get is what you are supposed to get. Typically, you want to try with a few different values, especially those that you suspect could cause you a problem. For example, let say you have class called Math with a method .modulo(int n1, int n2), then you would want to verify that Math.modulo(4,4) gives you 0, that Math.modulo(100,49) gives you 2 and that Math.modulo(2,0) throws an ExceptionDivisionBy Zero, etc. There really isn't much more to it than this. You barely even have to use your brain. Which is why it's one of the most mindnumbingly boring things programmers have to do.
To be frank, I have to admit I often skip this step altogether. I find it less boring to program the other classes right way and wait until I see bugs during the integrating testing phase. It's actually a very bad habit from my part because sometime it can produce hidden bugs that you don't detect until it's too late. And it can also make a simple bug more difficult to resolve because it's harder to detect where a problem is coming from when every parts of a software are working together than when you are only testing one class.
