Files
@ cec84c4675ce
Branch filter:
Location: kallithea/scripts/shortlog.py - annotation
cec84c4675ce
1.0 KiB
text/x-python
tests: remove race condition in test_forgot_password
One in so many times, test_forgot_password failed with:
kallithea/tests/functional/test_login.py:427: in test_forgot_password
assert '\n%s\n' % token in body
E assert ('\n%s\n' % 'd71ad3ed3c6ca637ad00b7098828d33c56579201') in
"Password Reset Request\n\nHello passwd reset,\n\nWe have received a
request to reset the password for your account.\n\nTo
s...7e89326ca372ade1d424dafb106d824cddb\n\nIf it weren't you who
requested the password reset, just disregard this message.\n"
i.e. the expected token is not the one in the email.
The token is calculated based on a timestamp (among others). And the token
is calculated twice: once in the real code and once in the test, each time
on a slightly different timestamp. Even though there is flooring of the
timestamp to a second resolution, there will always be a race condition
where the two timestamps floor to a different second, e.g. 4.99 vs 5.01.
The problem can be reproduced reliably by adding a sleep of e.g. 2 seconds
before generating the password reset mail (after the test has already
calculated the expected token).
Solve this problem by mocking the time.time() used to generate the
timestamp, so that the timestamp used for the real token is the same as the
one used for the expected token in the test.
One in so many times, test_forgot_password failed with:
kallithea/tests/functional/test_login.py:427: in test_forgot_password
assert '\n%s\n' % token in body
E assert ('\n%s\n' % 'd71ad3ed3c6ca637ad00b7098828d33c56579201') in
"Password Reset Request\n\nHello passwd reset,\n\nWe have received a
request to reset the password for your account.\n\nTo
s...7e89326ca372ade1d424dafb106d824cddb\n\nIf it weren't you who
requested the password reset, just disregard this message.\n"
i.e. the expected token is not the one in the email.
The token is calculated based on a timestamp (among others). And the token
is calculated twice: once in the real code and once in the test, each time
on a slightly different timestamp. Even though there is flooring of the
timestamp to a second resolution, there will always be a race condition
where the two timestamps floor to a different second, e.g. 4.99 vs 5.01.
The problem can be reproduced reliably by adding a sleep of e.g. 2 seconds
before generating the password reset mail (after the test has already
calculated the expected token).
Solve this problem by mocking the time.time() used to generate the
timestamp, so that the timestamp used for the real token is the same as the
one used for the expected token in the test.
30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 0a277465fddf 30e3d0a14f09 30e3d0a14f09 0a277465fddf 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 30e3d0a14f09 | #!/usr/bin/env python2
# -*- coding: utf-8 -*-
"""
Kallithea script for generating a quick overview of contributors and their
commit counts in a given revision set.
"""
import argparse
import os
from collections import Counter
import contributor_data
def main():
parser = argparse.ArgumentParser(description='Generate a list of committers and commit counts.')
parser.add_argument('revset',
help='revision set specifying the commits to count')
args = parser.parse_args()
repo_entries = [
(contributor_data.name_fixes.get(name) or contributor_data.name_fixes.get(name.rsplit('<', 1)[0].strip()) or name).rsplit('<', 1)[0].strip()
for name in (line.strip()
for line in os.popen("""hg log -r '%s' -T '{author}\n'""" % args.revset).readlines())
]
counter = Counter(repo_entries)
for name, count in counter.most_common():
if name == '':
continue
print('%4s %s' % (count, name))
if __name__ == '__main__':
main()
|