Quickcheck test for RTQ #169
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Jan 18, 2013
Closed
Closed
Closed
|
If trimming happens, if you don't apply the trim to the model, how can the expectation as to what the next item to be popped from the queue hold? |
ghost
assigned 
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is @Vagabond's QC test for the repl RT queue.
The only real addition is setting the max # of bytes in the queue before starting to exercise q trimming.
Initially, I started down the path of keeping a shadow ETS table in the QC model, but the model ended up using most of the trimming code from the rtq to shadow the size of the queue. This did not seem ideal as the test was using the same code that it was testing. Now I only assert that the queue size is always <= max_bytes which is set upon test startup.
What else should this test include?