From: Zooko O'Whielacronx Date: Tue, 10 Feb 2009 02:01:49 +0000 (-0700) Subject: immutable: test: add a test after attempting to repair from corruption: does a full... X-Git-Tag: allmydata-tahoe-1.3.0~55 X-Git-Url: https://git.rkrishnan.org/components/%22news.html/...?a=commitdiff_plain;h=bbf48f4a8843d881c6296ec509d934ca959052f4;p=tahoe-lafs%2Ftahoe-lafs.git immutable: test: add a test after attempting to repair from corruption: does a full verify run give the file a clean bill of health? If not, the you haven't successfully repaired it. This will make the repairer tests more consistent -- less accidentally passing due to getting lucky. --- diff --git a/src/allmydata/test/test_repairer.py b/src/allmydata/test/test_repairer.py index 2bb7d604..ed74e572 100644 --- a/src/allmydata/test/test_repairer.py +++ b/src/allmydata/test/test_repairer.py @@ -434,15 +434,24 @@ class Repairer(common.ShareManglingMixin, unittest.TestCase): shares = self.find_shares() self.failIf(len(shares) < 10) + # Now we assert that the verifier reports the file as healthy. + d3 = self.filenode.check(Monitor(), verify=True) + def _after_verify(verifyresults): + self.failUnless(verifyresults.is_healthy()) + d3.addCallback(_after_verify) + # Now we delete seven of the other shares, then try to # download the file and assert that it succeeds at # downloading and has the right contents. This can't work # unless it has already repaired the previously-deleted share # #2. - for sharenum in range(3, 10): - self._delete_a_share(sharenum=sharenum) + def _then_delete_7_and_try_a_download(unused=None): + for sharenum in range(3, 10): + self._delete_a_share(sharenum=sharenum) - return self._download_and_check_plaintext() + return self._download_and_check_plaintext() + d3.addCallback(_then_delete_7_and_try_a_download) + return d3 d2.addCallback(_after_repair) return d2