We'll pull code from all assignment repositories at 12am when assignments are due (and again on the following days for late submissions).
Afterwards, grading is done automatically using JUnit tests—the same stuff you'll be using throughout the course! For this first assignment, we'll only grade according to our provided tests, but future assignments will also be graded on additional secret tests. (The content of these tests will not be released, even after the due date.) This means that passing all the provided tests does not guarantee 100% correctness. Instead, you should write your own test cases to help guarantee the correctness of your code. As the quarter progresses, we will provide fewer and fewer tests.
We only grade the files that we explicitly say are to be modified (this information is located on the assignment page). This rule is also true for JUnit tests being graded. This also means that it is never safe to change the public interfaces of any code we provide: this includes (but is not limited to) adding new constructors, adding public helper methods, changing the expected behavior of public methods. Once again, if you change any file in a way that prevents your code from compiling when we're grading, we may not grade your code, and you'll get a zero on the assignment.
We grade the code you implement based on the following categories:
We grade your test files by running them against some of our implementations of the tested code: 1 fully correct solution and several incorrect solutions.
We check that each incorrect solution fails at least one of your tests. If no problems are detected with an incorrect solution, points are deducted for that specific implementation. The fully correct solution (matches what the specification requires exactly) should pass all your tests. If it fails any test, you will receive a 0 for this testing section. The reasoning behind this is that if tests say a correct solution is faulty, they'll almost definitely say buggy solutions are faulty, and would get all the rest of the points in this section for free (even if that test is completely wrong).
Note: If your implementation is wrong and your tests will likely end up wrong as well. You should review the specification (comments + assignment page) thoroughly to make sure your tests match what is required. You should also write tests to cover many possible cases so that you convince yourself your code is completely correct.
Note: If you submit a test without any timeout defined at all, we will add a timeout of 15 seconds. Additionally, if your test file takes longer than 1 minute to run all its tests, we may skip or delay grading your tests in order to give everyone timely feedback. (Since we need to run your tests once for each of our implementations, if every group uses 1 minute for each run, grading everyone's tests will take approximately 24 hours.)