-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: unit tests #329
RFC: unit tests #329
Conversation
Codecov Report
@@ Coverage Diff @@
## master #329 +/- ##
==========================================
- Coverage 96.47% 94.79% -1.69%
==========================================
Files 31 34 +3
Lines 4537 4837 +300
==========================================
+ Hits 4377 4585 +208
- Misses 160 252 +92
Continue to review full report at Codecov.
|
Another reason to split these tests apart. |
src/Test/atomic_tests.jl
Outdated
""" | ||
This function tests adding a single variable. | ||
""" | ||
function add_variable(model::MOI.ModelLike, config::TestConfig) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be more consistent with the rest of the tests to call it addvariabletest
This is related to the question : Should a solver error if |
I guess we can just leave each solver to have a default. Otherwise despite the backend having a default sense, every MOIWrapper will have to store a flag indicating whether the sense has been set. |
I had to exclude a few of the atomic tests since MockOptimizer doesn't implement names. |
Yes, that is the reason, we stay vague on this issue. |
Should be fixed in #336 :) |
src/Test/AtomicTests/constraints.jl
Outdated
Test getting constraints by name. | ||
""" | ||
function getconstraint(model::MOI.ModelLike, config::TestConfig) | ||
MOI.empty!(model) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's weird that we have to call MOI.empty!
at the beginning of every test. This should happen somewhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. Maybe it should go here?
https://github.com/JuliaOpt/MathOptInterface.jl/blob/84c5b19fa7cea292b715f6e02658bf977db08134/src/Test/config.jl#L42-L43
That can be a job for a different PR.
src/Test/AtomicTests/objectives.jl
Outdated
MOI.empty!(model) | ||
@test MOI.isempty(model) | ||
MOIU.loadfromstring!(model,""" | ||
variables: x |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great use of loadfromstring!
src/Test/AtomicTests/objectives.jl
Outdated
""" | ||
Test constant in objective. | ||
""" | ||
function constant_obj(model::MOI.ModelLike, config::TestConfig) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the test calls optimize!
, I'd propose to have "solve" somewhere in the name, like solve_constant_obj
. You could easily think that constant_obj
would just set and get the objective attribute without solving.
src/Test/AtomicTests/variables.jl
Outdated
atomictests["variablenames"] = variablenames | ||
|
||
""" | ||
Test the setting of an upper bound |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another example where "solve" in the name would be informative, e.g., solve_with_upperbound
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a big improvement for the tests. "Atomic" is a bit of a misnomer because some of the tests do more than one thing (e.g., delete_variables
). You could call these small tests or unit tests.
"solve_with_lowerbound", | ||
"solve_with_upperbound", | ||
"getconstraint", | ||
"getvariable", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getconstraint
, getvariable
and variablenames
should work now that #336 is merged.
You can test the solve
tests with mock_optimize
https://github.com/JuliaOpt/MathOptInterface.jl/blob/da6e0910d382ce83b047991d0ba6c6bfece4ddc1/src/Utilities/mockoptimizer.jl#L271-L281
See https://github.com/JuliaOpt/MathOptInterface.jl/blob/master/test/contlinear.jl for example for using mock_optimize
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that the mock optimizer implements the names correctly. I got some errors. I'm going to merge this as is, the outstanding tests can be addressed in later PR's.
src/Test/UnitTests/variables.jl
Outdated
unittests["variablenames"] = variablenames | ||
|
||
""" | ||
Test the setting of an upper bound |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also update the docstring to mention that the test calls optimize!
.
src/Test/UnitTests/variables.jl
Outdated
unittests["solve_with_upperbound"] = solve_with_upperbound | ||
|
||
""" | ||
Test the setting of an lower bound |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
This PR adds some atomic tests that aim to minimally test each expected feature in addition to the full end-to-end tests in
contlinear.jl
etc.It has already found a few bugs in LinQuadOptInterface that weren't following the API to the letter.
Bug fixes to existing tests
Questions
- Should we enforce a default objective sense?Raised as separate issue #335Other
Closes #244