我是一家软件公司的毕业实习生。他们告诉我要学习单元测试并为3个星期内大约有3000行和35个类的项目编写单元测试。我在2天内读过单位测试艺术，并且已经习惯了单位测试。你认为这是可行的吗？
答案 0 :(得分：6)
忽略单元测试应该在开发之前/期间编写的事实，我会说这是可能的。它可能是一个正确的婊子，但它绝对是可能的。
在这种情况下，最困难的部分是熟悉代码，以了解每个方法应该做什么，而不是代码所说的代码是这样做。如果您正在编写测试以传递当前代码，则测试错误是没有意义的。 （这一点可以追溯到单元测试应该在之前/期间写入的事实。）
您可能最终会获得较高的代码覆盖率，但最终可能会遗漏一些代码执行路径和边缘情况，这些代码执行路径和边缘情况在编写方法时应该/将要解决。在这种情况下，当出现错误或错误时，请确定为该情况编写一些测试，以便一旦修复该错误，就永远不会将其重新引入应用程序。
我会说，公司编写一个这样大小的整个项目并等待将毕业后的测试写入毕业实习生之后是相当糟糕的形式，但是只是我的意见。
答案 1 :(得分：2)
措词：
单元测试=测试一个单元/类/功能，独立于其他单元/类/功能，独立于整个解决方案/工作流程/ gui。
我认为，如果代码没有针对可测试性进行优化，那么在项目完成之后编写unittests（）是非常困难和昂贵的。
我有同样的问题，并决定编写集成测试，而不是测试工作流的整个应用程序逻辑，其中所有非gui组件一起工作但没有gui组件。幸运的是，这是可能的，因为gui和业务逻辑之间存在良好的分离。
然后我开始为我必须扩展的模块创建unittest-tests。
单元测试和集成测试的我使用了junit和nunit。