Here's my own approach to modelling and debugging (slightly adapted from a text I wrote about another CP system to OR-tools):
Preamble: Debugging a constraint model requires a different approach than debugging a traditional non-constraint program. The reason is that in a constraint model, everything “happens at the same time” when solve() has been started. This means that the traditional “print debugging” does not work in the same way.
• Test early and often. For a beginner, it can be good practice to test the model after each new constraint is added.
• Check the domains.
• First test with a small instance that has a known output, in order to ensure that the model is correct. Testing is much simpler with small instances, since it will be faster to solve and easier to check the solutions.
• If a model doesn’t work:
– Remove one constraint after another and test again. Or: Comment all constraints and add them one after one.
– Check the domains again.
• In order to ensure correctness of the model, it might be a good idea to count the number of solutions . For example, the 8-queens problem should give 92 solutions without symmetry breaking.
A (good) Sudoku problem should have exactly one solution: try to find 2 solutions and if there are more than one solution the model is not correct. One can use StopSearch in a solution printer to stop after 2 solutions.
• Print intermediate values in optimization problems via a solution printer.
• If the model is too slow: Test different search strategies/solver.parameters to speed up the search.