Permalink
Browse files

SETNX regression tests.

  • Loading branch information...
pietern authored and antirez committed Jun 13, 2011
1 parent 0df2e5b commit 5afce9b6eaf294e5e11004897a00484925f3790c
Showing with 38 additions and 11 deletions.
  1. +38 −11 tests/unit/basic.tcl
View
@@ -138,21 +138,48 @@ start_server {tags {"basic"}} {
r decrby novar 17179869185
} {-1}
- test {SETNX target key missing} {
- r setnx novar2 foobared
- r get novar2
- } {foobared}
+ test "SETNX target key missing" {
+ r del novar
+ assert_equal 1 [r setnx novar foobared]
+ assert_equal "foobared" [r get novar]
+ }
- test {SETNX target key exists} {
- r setnx novar2 blabla
- r get novar2
- } {foobared}
+ test "SETNX target key exists" {
+ r set novar foobared
+ assert_equal 0 [r setnx novar blabla]
+ assert_equal "foobared" [r get novar]
+ }
- test {SETNX against volatile key} {
+ test "SETNX against not-expired volatile key" {
r set x 10
r expire x 10000
- list [r setnx x 20] [r get x]
- } {0 10}
+ assert_equal 0 [r setnx x 20]
+ assert_equal 10 [r get x]
+ }
+
+ test "SETNX against expired volatile key" {
+ # Make it very unlikely for the key this test uses to be expired by the
+ # active expiry cycle. This is tightly coupled to the implementation of
+ # active expiry and dbAdd() but currently the only way to test that
+ # SETNX expires a key when it should have been.
+ for {set x 0} {$x < 9999} {incr x} {
+ r setex key-$x 3600 value
+ }
+
+ # This will be one of 10000 expiring keys. A cycle is executed every
+ # 100ms, sampling 10 keys for being expired or not. This key will be
+ # expired for at most 1s when we wait 2s, resulting in a total sample
+ # of 100 keys. The probability of the success of this test being a
+ # false positive is therefore approx. 1%.
+ r set x 10
+ r expire x 1
+
+ # Wait for the key to expire
+ after 2000
+
+ assert_equal 1 [r setnx x 20]
+ assert_equal 20 [r get x]
+ }
test {EXISTS} {
set res {}

0 comments on commit 5afce9b

Please sign in to comment.