Tests

Provided Test Classes¶

The test cases that you can run locally are in the directory ~/deques/test/deques. There are two ways to run tests for your implementations;

1. You may try to run BaseDequeTests, then choose one or all of the implementations to test.
2. You may run ArrayDequeTests directly to test your ArrayDeque, and run LinkedDequeTests directly to test your LinkedDeque implementation.

You should know why these work and how these tests are structured to write your own tests and to make good use of the debugging features.

In these projects, we are often testing different implementations of the same ADT, meaning that we are testing for identical functionality. Therefore, it makes sense for the code that tests each of these implementations to look similar.

• We can share the similar parts of code by using an abstract base test class.
• We create subclasses, one for each implementation of the ADT, to implement the code that cannot be shared.
• In this assignment, the base test class is BaseDequeTests. Its subclasses are ArrayDequeTests and LinkedDequeTests.

In these base test classes, each test (which is a method tagged @Test) calls an abstract method to obtain an instance of the class to test. When we choose an implementation (ArrayDeque or LinkedDeque), the subclass overrides the abstract method to construct instances of the different ADT implementations.

This design pattern has dedicated support in IntelliJ, so attempting to run an abstract test class or method in BaseDequeTests will provide a menu allowing you to select which implementation to run.

Grader-Only Tests¶

Your code for this and all future assignments will be graded based on some tests that are not provided with the skeleton code. These are run exclusively in Gradescope.

Usually, these grader-only tests either:

1. involve some setup that is too confusing to be useful (or some code that we simply cannot provide, e.g., when we need to time submissions against our solution code),
2. or are test cases that we’ve intentionally decided to withhold in order to encourage you to write your own tests and think about your own code.

This second point is particularly important. If you find yourself wondering why your code fails a grader-only test, write a test to replicate the failure. Afterwards, you’ll be able to use the debugger to investigate the issue.

Submission Rate Limiting¶

From this project onward, we will be implementing a rate limit on Gradescope to discourage you from abusing the autograder system (e.g., by spamming submissions just to see feedback on grader-only tests, without thinking about changes you’re making).

The rate limit can be thought of in terms of submission tokens. At the start of each project, you will get the maximum number of tokens, 6, and each submission consumes 1 token. Tokens recharge at a rate of 1 every 10 minutes up to the max number of tokens. If you make a submission with no tokens remaining, your submission will not be graded, and you’ll need to resubmit after you get a token back. The submission feedback on Gradescope should include the time of your next token recharge.)

The rate limiting also has the added benefit of making students start early on assignments and allow students to take breaks without making you feel like you’re “wasting” tokens. If you’re having a hard time writing or debugging some code, it will often be more efficient to take a break and return later with a fresh mindset, rather than repeatedly bashing your head against the problem.