You don't test private methods directly, but indirectly through public methods that call them.
Why not ? If you have the code why not make them Public/Protected for debugging. And then write tests for them too.
When your class is nearly finished it's hard (but not impossible) to write test afterwards.
You normally test from the ground-up you start with the basic-function and go higher and higher trough your class.
Think of it as a big building, you start /and test the fundament then the cellar, then go floor by floor to the roof.
Start with the following trought:
- What do You expect from a function ?
- What do you NOT expect ?
- where are the boundaries ?
- what happens if the input-parameters exceed these boundaries?
Then write a test fire as many input-parameter at you function as you can think of, e.G:
- if your Procedure/Function takes a byte/word a for-loop giong from 0 to 255/65535 is ok modern computers do that in a matter of milliseconds, and you can be shure to have all input values testet.
- Integer, int64, floatingpoint and strings are another case.
The
Monte-Carlo-Methode comes in handy here, meaning use a Random-Number/String-Generator that generates a sufficient number of tests e.G: >200000
(that depends on How much time you want to spend and how save it has to be).
To test the function DO NOT just copy the code of the function and test against it.
Think of a slightly different method to check the result.
FPC-Unit-Test is a test-Framework you can use.
It helps you organize your tests.
As I said it's much better to do TDD (
Test-Driven-Development).
Whenever you want to create something, start with the test, and falsify it, because the function is not there yet, then create the function and your test succeeds ... and so on. When you think about a function it's just a small amount of brain-power to think about a test. And when you have it, you can test whenever you add a new function, that this doesn't influence the already existing functions.