我有一个队列对象,它在我的项目中起着非常重要的作用,我不能容忍其中出现任何错误。
它的想法就像内置的Queue
(它的基类)一样,但它将数据或至少部分数据存储在文件中以保留内存。我决定将其中一些内容保留在内存中,因为这样可以加快速度。我已经输入代码here ,看到它可能比我解释它更容易
这似乎是一件奇怪的事情,但我需要排队很多工作,排队的速度比我完成它的速度要快得多,而且如果我使用标准<,它将使用太多内存队列
。我不能只在队列上放置一个 maxsize 并阻止工作人员将数据放入队列中,因为我想尽快知道要处理的数据总量。我也无法先计算出总数,但不能将其排队,然后返回放入 Queue
,因为每次查看数据时总数都会不同,最后总数不匹配。
我的问题是如何彻底测试这一点,以确保没有项目丢失,或更重要的是,当缓冲区或文件中仍有项目时,或者在调用完成并且队列已完成后, setter/getter 上没有任何阻塞空。
当您知道某些给定输入的输出应该是什么时,有些事情似乎很容易测试和设置单元测试,但是测试这样的东西我不太确定是否有有效的方法。是否可以通过单元测试来测试这种事情?
我已经设置了一个测试程序,可以以不同的速度放入和获取不同数量的项目,看起来不错,但我已经看到 .get 上有 getter 阻塞的证据
项目仍在队列中,所以我相信存在问题。
我可以彻底测试它以找到任何剩余错误或接近确定它没有错误的最佳方法是什么?
编辑
可以生成一些类似于我在以下代码中使用的测试数据,在项目中的某些条件下我只有文件的校验和,而其他时候它是None
所以我只是生成它有时在下面的代码中尝试并模拟
import os
import hashlib
def hash(f_obj):
md5 = hashlib.md5()
while True:
data = f_obj.read(8192)
if not data:
break
md5.update(data)
return md5.hexdigest()
def produce(at_once,total_items):
items=[]
count=0
for dir,folders,files in os.walk("/"):
for f in files:
try:
f_path= os.path.join(dir,f)
f_size= os.path.getsize(f_path)
f_mtime= os.path.getmtime(f_path)
with open(f_path) as file_obj:
f_hash= hash(file_obj) if f_size%2 else None
items.append((f_path,f_size,f_mtime,f_hash))
count+=1
except Exception as err:
print "#####",err,"#####"
if len(items) >= at_once:
yield items
items=[]
if count >= total_items:
break
if items:
yield items
最佳答案
我编写了一些类似的组件。
我验证其正确性的策略通常有三部分:
- 检查代码。我会在编写代码一两天后尝试彻底审查代码,特别注意我认为可能有问题的地方。如果可能的话,我也会请同事审阅。
- 单元测试验证其在“明显”情况和边缘情况下表现良好。它们有助于确认不存在愚蠢的错误,并有助于防止 future 的回归……但我通常不希望发现令人惊讶的错误。
- 压力测试脚本。该脚本将生成一堆线程,“随机”执行读取和写入,确保不会发生爆炸。我的第一个版本通常是完全随机的,但随着我的进一步开发,我会为其添加一些智能。我将确保“随机”读/写将偏向于触发复杂的代码路径(例如,在您的示例中,偏向于溢出到 gzip 文件,然后从该文件读回),我将跟踪该数字应该在队列中的项目(以检测错误的阻塞操作),并且我将改变读取器和写入器的数量。一旦我可以让这个脚本运行一段时间而不发生任何崩溃,我就会相当有信心我的队列是好的。
到目前为止,我使用此方法验证的队列在生产中表现坚如磐石。
关于python - 如何调试这个缓冲文件队列?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10953272/