Document MOIT in manual

[blegat]

We could also add docstrings to each test (e.g. with the program that is solved in LaTeX) and list them in the doc.

[odow]

I started to do this and realized that a lot of the test functions are huge monoliths with lots of complicated stuff going on where it's all or nothing. They should probably be broken up into atomic tests that each test one little thing rather than test X, then test Y, then test Z, then...

[mlubin]

They should probably be broken up into atomic tests that each test one little thing rather than test X, then test Y, then test Z, then...

Absolutely.

[joaquimg]

+1
But I would just add small version without discarding the existing ones.

[blegat]

I started to do this and realized that a lot of the test functions are huge monoliths with lots of complicated stuff going on where it's all or nothing

I think this is mostly the case of contlinear1 :-P it does many checks on the models. If we include this in separate tests we have the risk that solver writers forget to use these tests.

[joaquimg]

I think we should have two layers:

• minimal unitary tests that are great for initial development and finding some simple issues
• complex tests like contlinear1

Many errors only show up after doing some of those crazy modifications like adding and removing a few variables and then trying to change bounds of the remaining ones... I found a few corner cases using contlinear1.

[mlubin]

@joaquimg, I agree that there should be some complex tests like contlinear1, but ideally we should have many minimal unit tests and just a small number of more complex tests that test everything at once. When we want to test just one more thing (e.g., #244), we should prefer to do it by adding a new unit test rather than modifying a larger test.