对于有提示框的代码，大家是如何做单元测试的？
开发环境VS2008，用自带的测试方式，按常规写单元测试代码，如果被测试的代码中有MessageBox.Show的提示，测试就要人工点击一下才能继续。

请教大家对此是如何处理的？
------解决方案--------------------
自己写一个MessagwBox类，也使用System.Windows.Forms命名控件，将系统的那个用别名重定向掉，让测试的工程使用这个类。
------解决方案--------------------
对于自动测试设计者，它设计测试用例通常恰好在于“有本事模拟用户操作行为”为基准的，也就是说不会以“等待用户操作”为测试用例！

假设你纠结于“提示框”，那么你或者看看你们是不是新招聘了什么“愣头青”式的实习生从而胡乱写没有意义的代码，或者你就看看你们的设计是否到位？！

一个到位的设计，其目的就是模拟用户的连串的行为，而不是什么等待用户操作。如果没有本事连续模拟用户行为，它早就分为以此为分割点而分为两个测试用例了！
------解决方案--------------------
你可以找个基于改写IL代码方式的mock类库，比如TypeMock可以这样用：
Isolate.WhenCalled(MessageBox.Show).WillReturn(ok);
------解决方案--------------------
自动测试是有一定的尺度的，超过这个度你就根本没有达到需要纠结那么多东西的地步。

比如说如果你必须预先规定必须非得是MessageBox.Show的话，这种规定作为“设计”有多大意义？难道UI/UE设计师选择一个漂亮的自定义对话框就不行了吗？你就一定要纠结在这个点上，而不能把它做为前后两个测试用例的分割点吗？

实际上这是体现着“你到底是测试驱动开发，还是那种测试跟在编码屁股后边的开发”两种方法的区别。如果是测试驱动开发，你的程序员做的工作是可以测试的，但是你会把一些随时需要变得很酷的设计工作交给真正的UI设计师去开发，这些人几乎根本不写代码并且随时使用美工板来修改UI设计，几乎无法自动化测试。


------解决方案--------------------
简单的说就是在设计阶段就把数据逻辑与UI分离。

自动化测试基本上是模拟用户或外界系统的输入，证明可以获得正确的结果。

至于用户如何输入，结果如何展示，就是UI的事了。
UI的自动化测试，需要太多的额外开发，实在不合算。