Isolate and expand snapshot test

[vweevers]

abstract-leveldown/abstract/iterator-test.js

Lines 147 to 169 in 88b8900

	module.exports.snapshot = function (leveldown, test, testCommon) {
	test('setUp #2', function (t) {
	db.close(function () {
	db = leveldown(testCommon.location())
	db.open(function () {
	db.put('foobatch1', 'bar1', t.end.bind(t))
	})
	})
	})
	test('iterator create snapshot correctly', function (t) {
	var iterator = db.iterator()
	db.del('foobatch1', function () {
	iterator.next(function (err, key, value) {
	t.error(err)
	t.ok(key, 'got a key')
	t.is(key.toString(), 'foobatch1', 'correct key')
	t.is(value.toString(), 'bar1', 'correct value')
	iterator.end(t.end.bind(t))
	})
	})
	})
	}

• Move to iterator-snapshot-test.js for skippability (closes Snapshot test - do we really need it? #38)
  • Skip db.close in setUp
  • Copy tearDown
• Add tests (supersedes Add tests for concurrent delete/iteration #46):
  • put (overwrite value) before next
  • put (add new key that sorts first) before next
  • batch (delete key) before next superfluous
  • batch (overwrite value) before next superfluous
  • batch (add new key that sorts first) before next superfluous

[vweevers]

Ah wait, I misunderstood something. #46 is not about testing snapshot guarantees. If it was, the proposed tests would be fallacies as they don't assert that a deleted key can still be read by the iterator, just that the next key can be read.

Rather, these tests are specifically for stores that don't support snapshotting. In that case, their iterators must ignore keys that have been deleted in the meantime.