Tests

Provided Test Classes¶

Given that we’ll often be working with different implementations of an ADT that provide identical functionality, it stands to reason that the code for testing the functionality of different implementations would also look similar.

In order to share test code, our provided tests are often written in an abstract base test class, where each test method calls an abstract method to obtain the instance of the class to test. This way, we can create multiple sub-test-classes of this base test class, each overriding the abstract method to construct instances of the different ADT implementations.

In this assignment, the base test class is BaseDequeTests, and its subclasses ArrayDequeTests and LinkedDequeTests test ArrayDeque and LinkedDeque respectively.

As it turns out, this design pattern has dedicated support in IntelliJ, so attempting to run an abstract test class or a test method in one of them will cause IntelliJ to bring up 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 and run exclusively on 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.