事实上Pro和Con的单元测试(Pro's and Con's of unit testing after the fact)

事实上Pro和Con的单元测试(Pro's and Con's of unit testing after the fact)

我有一个大约27k线的复杂的应用程序。 它基本上是一个规则驱动多线程处理引擎，而不会给予太多的损耗。它已经被部分测试，因为它已经构建了某些组件。

问题是，事实之后，可以说，在执行之后，亲和做单位测试是什么。 很显然，传统测试将需要2-3个月的时间来测试每一个方面，所有这些测试都需要工作，那个时候真的没有。

过去我做了很多单元测试，但是一般来说，它已经在台式机自动化或者LOB应用程序上了，这些应用相当简单。 该应用程序本身在内部高度组件化，界面驱动真正。 我还没有决定使用什么特定的框架。 任何建议将不胜感激。

什么说你

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.

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.

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.

What say you.

最满意答案

根据“手动测试”有多少错误，您可以简单地进行测试驱动的错误修复 ，这在我的经验中比通过编写“验尸”单元测试简单地提升代码覆盖率更有效。

（这不是说后面的单位测试是一个坏主意，只是TDD几乎总是一个更好的主意 。）

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.

(Which is not to say writing unit tests afterwards is a bad idea, it's just that TDD is almost always a better idea.)