编写一个会暴露常见内存问题的标准化TDD [测试]方法是否有用?
这组测试可以轻松,快速地应用于某个方法,并且会使“经典”.NET内存问题失败,但会使经典解决方案失效。
例如,常见的内存问题可能是:垃圾收集器进行了太多的重定位 ;分配太多;太多的垃圾收集(经典的例子比字符串reallocs更喜欢StringBuilder);坚持记忆太久(经典的例子呼吁处理并且不依赖于终结者);对象不恰当地达到g1,g2,LOH;随着时间的推移,......以及其他方面的小泄漏会增加一些重要的东西。
也许代码可能看起来像这样......
[Test]
public void Verify_MyMethodUnderTest_Is_Unlikely_To_Have_Common_Memory_Problem()
{
//-Setup
var ExpectationToleranceA = ...
var ExpectationToleranceB = ...
...
//-Execute
var MeasurementA = MyClassUnderTest.MyMethodUnderTest( dependancyA ) ;
var MeasurementB = MyClassUnderTest.MyMethodUnderTest( dependancyB ) ;
…
//-Verfiy
Assert.That( MeasurementA , Is.WithinTolerance( ExpectationToleranceA ) ) ;
Assert.That( MeasurementB , Is.WithinTolerance( ExpectationToleranceB ) ) ;
}
还有关于内存压力问题的其他帖子,但这里的想法是能够快速指出一个方法的标准测试,并且测试会在常见/经典内存压力问题上出现红色失败但是绿色通过常见解决方案。然后可以指示开发人员查看失败的代码并可能修复泄漏,更改公差甚至删除TDD内存压力测试。
这个想法有腿吗?
这里有一个与C ++ app Memory leak detection while running unit tests相关的问题,这是一个类似的问题,但不完全相同。在所有测试运行后,Twk的问题指向内存......
我的想法是.NET 1)单元测试每种方法的常见内存问题 2)经典的内存问题失败了 3)将经典修复传递给经典的常见内存问题 4)能够快速地在功能上进行快速标准测试以查看它是否表现出典型症状 5)能够升级单元测试中应用的标准TDD .Net内存压力测试。这意味着上述代码的重构,以便升级到标准测试将改变整个Nunit测试套件中为项目应用的内存测试的升级。
(p.s。我知道没有Is.WithinTolerance电话,但我只是在展示一个想法。) 欢呼......
答案 0 :(得分:3)
单元测试通常最适合测试小部分功能。你所听到的有点像集成测试,它测试整个系统的行为和性能。
我看到这种方法的问题是系统中的任何给定单元可能不会生成这些与内存相关的错误。因此,即使你可以得到这样的东西,你也无法保证一旦你的单位整体工作就不会出现记忆问题。
所以我的建议是在多个州进行集成测试。在不同负载水平下测试系统,看看出现了什么样的内存问题(如果有的话)。这种测试对你更有益。
答案 1 :(得分:0)
我会说这是一个坏主意。如果你想编写“验证”垃圾收集器的某些行为的测试,你基本上是“测试”你无法控制的代码。垃圾收集器的确切行为是当前CLR的实现细节。它可能在将来发生变化,从而导致测试“失败”。在大多数情况下,您可能无法更改代码中的任何内容来“修复”测试,因此您不得不更改测试以反映新实现。在我看来,这种用途有限。
应使用单元测试来验证您自己的代码的意图,以便在更改破坏现有代码时通知您。使用它们来帮助开发和维护自己的代码。
根据我的经验,通过确保单元测试没有依赖性来实现最佳结果。执行您描述的测试意味着测试将对硬件和运行时系统有很多依赖性。
只需5美分。
答案 2 :(得分:0)
应该在小块代码上指出好的单元测试。理想情况下,当涉及垃圾收集器时,它们应该是可重复的,而不是这种情况。
尽管如此,可以使用单元测试框架工具进行非单元测试(功能测试,回归测试,压力测试......)。但是你需要 意识到 ,你没有进行真正的单元测试。因此,不要在某些自动构建中使用它们,也不要强迫其他开发人员在提交测试中包含此类测试。 实际单元测试可能不会受到非单元测试的影响!
如果要执行此类操作,请考虑在要测试的操作之前和之后调用GC.Collect()方法。连续多次调用可以更轻松地感知内存消耗的增长。考虑在单独的隔夜构建中添加此类测试(与实际单元测试分开),因为这可能非常耗时。在单独的计算机上调用测试,您可以完全控制(在测试期间打开带有一些Flash动画或病毒扫描程序的浏览器可能会弄乱您的结果)。将内存消耗的数据存储在某处以供稍后查看。这将使您意识到在长时间的开发周期中缓慢增加内存消耗。