Testing vs Debugger

       SharpDevelop的确是个很不错的开源IDE工具，但对于一些长期使用了VS的人来说，似乎有点美中不足。它没有象VS那样方便的Debuger，就如我的一个同事那样，将VC6的程序放到VC.NET上来编译，第一句话就问：监视内存的视图如何打开啊？
       以往的年代，从DOS平台的TC到Window平台的VS等著名的IDE开发工具，Debuger是必不缺少的，即使现在的JBuilder也还依旧保留了Debuger，但SharpDevelop却没有，它没有将Debuger作为一个必要的核心来对待，而只是简单的和NUnit来集成，用testing来替代Debuger，没有Debuger的开发似乎对于有些程序员来说是一种缺陷，但如果想深一层，现在平时项目开发中经常用Debuger的帮助到底有多大呢？以前我们长期依赖Debuger的原因是什么呢？
       以前用Debuger经常做的事情就是跟踪某个变量在运行过程中的变化和对内存的分配，释放等行为。而对于现在流行的.NET和Java平台(Managed Platform)，内存管理已经不用程序员担心了，如果仅仅为了跟踪某个变量就经常使用单步跟踪，是否有点大炮打蚊子的感觉？以往用Debuger还可以帮助我们提高程序的性能，了解错误发生的内部核心，从而修正而提高效率，而在今天，设计模式和一些编程技术日益完善，应用程序员的开发更多关心的是业务流程的正确性，跟踪和修正的问题似乎是业务上的问题多些，NUnit等的testing恰好是测试小模块业务逻辑正确性的利器。
       就自己而言，日常工作中用Debuger确实不是经常，如同SharpDevelop作者所提倡的那样，在编码中我喜欢用断言(Debug.Assert)来跟踪变量，而功能测试用NUnit足矣...

       你现在还经常用单步调试吗？

这里有篇类似的文章Testing is the New Debugging