我看到一些我维护的代码出了问题。下面的代码有一个private static SHA1成员(这是一个IDisposable,但由于它是static,所以永远不应该完成)。然而,在压力下,这段代码抛出了一个异常,表明它已经关闭:
Caught exception. Safe handle has been closed"
Stack trace: Call stack where exception was thrown
at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
我想知道你们是否有任何好的读物来考虑将什么归类为单元测试/验收/集成测试。我有以下场景,我们在工作中有一点争论,它是否应该在单元测试中:
在我们的数据访问层中,一些语句使用sql,例如"select * from people where id IN ('x','y')“,其中IN语句是根据输入动态生成的。最近我们发现,我们的Oracle数据库在IN语句中有1000个变量的限制。
我个人认为这不是单元测试场景。我们在单元测试中测试sql是否对数据库起作用,以及逻辑是否正确。但是,压力测试应该在更高的级别上进行。
如果我们要在单元测试中使用数千条记录进行测
我的程序是死锁的,下面是死锁的前4帧:
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
#1 0x00007f926250b7aa in _L_lock_12502 () at malloc.c:3507
#2 0x00007f926250a2df in malloc_atfork (sz=12, caller=<value optimized out>) at arena.c:217
#3 0x00007f926250881a in __li
根据我所读到的,单元测试线程安全没有“好的”通用解决方案。但我希望有一个解决具体问题的好办法。
让我们考虑这个(虚拟)动态列表实现。add方法显然不是线程安全的。既然让它成为线程安全(让我们考虑我们不会实现任何remove方法并保持它是虚拟的)是非常明显的,那么一个单元如何测试这段代码以表明它实际上并不是线程安全的,并且表明线程安全修复实际上是有效的(或者看起来是有效的)?
public class ArrayList {
private int capacity = 2;
private Object[] content = new Object[capacity];