You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you have two graders where one grader depends on the other (e.q. private and public grader) in a setup like this:
graders {
val graderPublic by creating {
graderName.set("Public")
rubricProviderName.set("RubricProvider-Public")
}
val graderPrivate by creating {
parent(graderPublic)
graderName.set("Private")
rubricProviderName.set("RubricProvider-Private")
}
}
and two identically named files in both graders it seems to continue the grading process with the file in the child grader when executing the parent grader. If the public grader consists of the class
You would expect the public grader to fail and the private grader to pass because the private grader, being the parent of the public grader, should overwrite the failing ExampleTest class of the public grader with its version of the class (which doesn't fail). But the actual behavior is that both graders fail. Renaming the ExampleTest class of the private grader leads to the expected behavior.
It seems like this bug was introduced with version 0.9.0.
The text was updated successfully, but these errors were encountered:
If you have two graders where one grader depends on the other (e.q. private and public grader) in a setup like this:
and two identically named files in both graders it seems to continue the grading process with the file in the child grader when executing the parent grader. If the public grader consists of the class
the private grader of the class
and both Rubrics being
You would expect the public grader to fail and the private grader to pass because the private grader, being the parent of the public grader, should overwrite the failing ExampleTest class of the public grader with its version of the class (which doesn't fail). But the actual behavior is that both graders fail. Renaming the ExampleTest class of the private grader leads to the expected behavior.
It seems like this bug was introduced with version 0.9.0.
The text was updated successfully, but these errors were encountered: