事后单元测试的利弊
我有一个大约 27k 行的大型复杂应用程序.它本质上是一个规则驱动的多线程处理引擎，不会泄露太多它在构建时已经过部分测试，某些组件.
I have a largish complex app around 27k lines. Its essentially a rule drive multithreaded processing engine, without giving too much away Its been partially tested as it's been built, certain components.
我的问题是，在事实之后进行单元测试的优缺点是什么，可以这么说，在它实施之后.很明显，传统的测试需要 2-3 个月以上的时间来测试每个方面，而且这一切都需要工作，而那个时间真的没有.
Question I have, is what is the pro's and con's of doing unit testing on after the fact, so to speak, after its been implemented. It is clear that traditional testing is going to take 2-3+ months to test every facet, and it all needs to work, and that time is not available really.
我过去做过相当多的单元测试，但通常是在桌面自动化或 LOB 应用程序上进行，这些都相当简单.该应用程序本身在内部是高度组件化的，真正由界面驱动.我还没有决定使用什么特定的框架.任何意见，将不胜感激.
I've done a fair bit of unit testing in the past, but generally it's been on desktop automation or LOB apps, which are fairly simple. The app is itself is highly componentized internally, interface driven really. I've not decided on what particular framework to use. Any advice would be appreciated.
你说什么.
根据手动测试"出现的错误数量，您可以简单地进行测试驱动的错误修复，根据我的经验，这是比简单地通过编写事后分析"单元测试来提高代码覆盖率要有效得多.
Depending on how many bugs "manual testing" turns up, you could simply do test-driven bug fixing which in my experience is far more effective than simply driving up code coverage by writing "post-mortem" unit tests.
(并不是说事后编写单元测试是个坏主意，只是TDD 几乎总是更好的主意.)
(Which is not to say writing unit tests afterwards is a bad idea, it's just that TDD is almost always a better idea.)